Download as PDF, PPTX
Uploaded byGino Farisano
Thread
Il documento discute l'evoluzione dei sistemi operativi avanzati, concentrandosi sull'importanza e sull'implementazione dei thread, con particolare attenzione a come la legge di Moore e l'architettura multicore influenzino le prestazioni. Viene analizzato il modello di threading, le loro implementazioni e vantaggi/svantaggi, oltre a fornire esempi pratici di programmazione in linguaggi come C e Java. Infine, si esaminano casi d'uso reali e sfide associate all'utilizzo dei thread nei sistemi interattivi.
Thread
- 1. Università degli Studidi Salerno Sistemi Operativi Avanzati THREAD Grano G. Farisano G. Prof. G. Cattaneo
- 2.
- 3.
- 4.
- 5.
- 6. Contesto storico (1) 20012005 gennaio 2006 luglio 2006 corsa ai Ghz (Prescott) Core i3, i5 i7 optimized for speed optimized for performance /watt IBM PowerPC POWER4 AMD Opteron «Le prestazioni dei processori, e il numero di transistor ad esso relativo, raddoppiano ogni 18 mesi» Pentium D Presler Pentium D Smithfield Athlon 64 X2 Core 2 Duo DIE singolo DIE doppio DIE monolitico
- 7. Contesto storico (2) •La prima legge di Moore è stata valida per un lungo periodo di tempo (primi anni 2000?) • Seconda legge di Moore: «il costo di una fabbrica di chip raddoppia da una generazione all'altra» • Troppi transistor da gestire • Impossibilità di aumentare la potenza • Bisogno di replicare i componenti (più cores nello stesso chip) • Necessità di migliori tool per localizzare il parallelismo e validare il codice parallelo
- 8.
- 9.
- 10. • Browser web: •Rappresentazione dei dati sullo schermo • Reperimento dati dalla rete • Elaboratore testi: • Acquisizione dati da tastiera • Visualizzazione sullo schermo • Correttore ortografico durante la battitura Applicazioni reali
- 11. • Tempo dirisposta • Condivisione delle risorse • Economia • Scalabilità Vantaggi
- 12. Svantaggi • Difficoltà diimplementazione • Sincronizzazione • Sezioni critiche, deadlock…
- 13. Creazione thread • Threadingasincrono • Threading sincrono
- 14. Thread models (1) •Thread di livello kernel - gestiti direttamente dal kernel • Thread di livello utente - gestiti mediante una libreria per i thread • Thread ibridi - thread di livello utente mappati su thread di livello kernel
- 15. Thread models (2) •Modello da molti a uno • Modello da uno a uno • Modello da molti a molti
- 16. Modello da moltia uno
- 17. Modello da unoa uno
- 18. Modello da moltia molti (1)
- 19. Modello da moltia molti (2)
- 20. Thread utente ekernel thread • Il modello molti-a-molti e il modello a due livelli richiedono comunicazione per mantenere il numero appropriato di kernel thread per gestire i thread utenti creati dall’applicazione • Solitamente, ad un thread utente è allocato un LWP (lightweight process), che la libreria dei thread utente vede come un processore virtuale • Ogni LWP viene eseguito da un thread del kernel
- 21.
- 22.
- 23.
- 24. Legge di Amdahl speedup 1 S + (1 S) N
- 25. Multithreading Supporto hardware daparte di un processore per eseguire più thread. Fine anni 90: fine ricerche su incremento dell’instruction level parallelism
- 26. Coarse-Grained Multithreading Context-switch adogni evento ad elevata latenza (cache miss) Vantaggi: • Non necessita di uno switch veloce • Non c’è un rallentamento dei thread Svantaggi: • La pipeline deve essere svuotata o congelata allo switch • Un nuovo thread deve riempire la pipeline
- 27. Fine-Grained Multithreading Switch trai thread ad ogni istruzione! Scheduling round-robin: skippati thread in stallo! Vantaggi: • Si nascondono gli stalli Svantaggi: • Si sacrificano le prestazioni di un singolo thread
- 28.
- 29.
- 30. POSIX Thread • Diverselibrerie proprietarie • Forte eterogeneità tra le varie librerie • Bisogno di un’interfaccia standard • Standard IEEE POSIX 1003.1c (PThreads) Definiti come insieme di tipi e procedure implementate in C. Composti da un file pthread.h e una libreria.
- 31. Perché Pthread? • LightWeight • Efficient Communications/Data Exchange • Overlapping CPU work with I/O • Priority/real time scheduling • Asynchronous event handling
- 32. Designing Threaded Programs parallelprogramming shared memory thread-safeness
- 33. PThread API • ThreadManagement: creazione, distruzione e join di thread • Mutexes Management: creazione, distruzione, lock e unlock di variabili di mutua esclusione (mutex) per la gestione di sezioni critiche • Condition Variables Management: creazione, distruzione, wait e signal su condition variable definite dal programmatore
- 34. Creazione dei thread pthread_create(thread, attr, start_routine, arg) Di default, un thread è creato con una serie di attributi. Alcuni di essi possono essere modificati dal programmatore pthread_attr_init (attr) e pthread_attr_destroy (attr)
- 35. Terminazione di unthread Un thread può terminare per diversi motivi: • la starting routine termina • il thread chiama la subroutine pthread_exit() • il thread viene cancellato da un altro thread con la routine pthread_cancel() • il processo main() termina per prima
- 36.
- 37. Joinable Threads Un modoper realizzare sincronizzazione tra thread La routine pthread_join() blocca chiamante finché il thread threadid specificato non termina. Un thread deve essere dichiarato come “joinable”:
- 38.
- 39. • Sequenziale • Pthread •OpenMP Moltiplicazione matriciale https://github.com/giograno/thread_so
- 40.
- 41.
- 42.
- 43.
- 44.
- 45. Thread Java(1) • Duepossibilità di creare un thread: - Creare una nuova classe derivata dalla classe Thread - J a v a n o n p r e v e d e l’ereditarietà multipla - Implementare l’interfaccia Runnable • L’API Java è anche disponibile per le applicazioni Android - Honeycomb SDK o superiori ci OBBLIGANO ad eseguire operazioni di rete in un Thread differente dal main thread android.os.NetworkOnMainThreadException
- 46. La JVM eil sistema operativo ospitante Thread Java(2)
- 47.
- 48. Thread di Linux FLAGSIGNIFICATO CLONE_FS Condivisione delle informazioni sul file system CLONE_VM Condivisione dello stesso spazio di memoria CLONE_SIGHAND Condivisione dei gestori dei segnali CLONE_FILES Condivisione di file aperti
- 49. Using Threads inInteractive Systems: A Case Study Carl Hauser, Christian Jacobi, Marvin Theimer, Brent Welch, Mak Weiser 14th ACM Symposium on Operating Systems Principle (SOSP-14), December 1993
- 51. Overview • Analisi didue grossi sistemi interattivi: Cedar e GVX • Obiettivi: 1. esaminare e classificare le feature comuni e i paradigmi di utilizzo dei thread 2. analizzare l’architettura di un ambiente thread- based 3. analizzare le più importanti proprietà di un sistema interattivo
- 52. Thread Model • Mesalanguage • Multiple, lightweight, preemptively scheduled threads in shared address space • FORK, JOIN, DETACH • Condition variable and monitors: - WAIT, NOTIFY, BROADCAST • Priorities • Finer grain
- 53. Dynamic behavior • Eternal:run forever, waiting on condition variable • Worker: perform some computation • Transient: thread with short life, forked off by long- lived thread
- 54. Thread Paradigms • Deferwork: single most common use; reduce latency • Pumps: components of pipeline • Sleepers and oneshots: wait for a triggering event and then execute • Deadlock avoiders: avoid violating lock order constraints
- 55. Thread Paradigms • Taskrejuvenation: recover from bad state; fork new copy of service or error reporting thread • Serializer: queue and thread processing from queue • Concurrency exploiters: for using multiple processors • Encapsulated forks: code modularity; not a really thread paradigm
- 56. Static Count (Cedar) 7% 1%4% 1% 3% 10% 7% 19%2% 14% 31% Defer Work General Pumps Slack Processes Sleepers Oneshot Deadlock Avoid Task Rejuvenate Serializer Encapsulated Fork Cuncurrency Exploiters Unknown and Other
- 57. Issues in threaduse Trade-off involving simplicity/concurrency and actual efficiency Easy uses: • Work deferrer, sleeper, one-shot, pump without critical constraint • Little interaction between threads
- 58. Hard thread useissue • Little guidance in literature and in their experience for using concurrency exploiters • Slack process and pumps w. timing constraint • X Window system performance - Slack process hight priority - YieldButNotToMe
- 59. Common usage mistakes •IF instead WHILE for monitors • Timeout hacks to compensate for missing NOTIFY • Timeout inappropriate values • Running out of resources • Spurious lock conflicts: thread notified, thread awakened, but notified still has lock
- 60. Xerox scientists’ conclusion •Studies were made of two interactive systems using threads heavily, and taxonomies draw up • Interesting difficulties were discovered both in use and implementation • Starting point for new studies
- 61. Challenges identificazione dei task dipendenzedei dati suddivisione dei dati testing bilanciamento