Soluzioni adottate

Il base alla capacit di un sistema di gestire i thread a livello del kernel, si distinguono 4 possibili combinazioni di utilizzo
1. singolo processo utente e singolo thread (MS-DOS); 2. singolo processo utente e multiplo thread per processo (JAVA); 3. multiplo processo utente e singolo thread per processo (UNIX); 4. multiplo processo utente e multiplo thread per processo (Linux)

Gli ambienti operativi hanno due modalit principali per realizzare un sistema multithreading a seconda che il kernel sia o meno a conoscenza della loro esistenza, cio se i thread vengono costruiti mediante chiamate al kernel oppure da software attraverso procedure e librerie. Nel primo caso si parla di Kernel-Level, nel secondo di User-Level

 Kernel-Level In questo caso il kernel gestisce i thread al pari di tutti gli altri processi assegnando loro risorse di sistema. Se un thread si sospende pu evolvere un secondo thread generato dallo stesso processo poich tra loro schedulati autonomamente. Lo stesso kernel pu essere scritto come un sistema multithread Linux, Unix e Windows realizzando ambienti Kernel-Level User-Level I thread a livello utente vengono implementati grazie a delle librerie apposite (thread package) che contengono funzioni per creare, terminare, sincronizzare i thread e per realizzare lo scheduling. N la schedulazione n lo switching con il cambio di contesto coinvolgono il kernel, che gestisce solo i processi. I thread risultano pertanto di propriet e gestione esclusiva del processo che li ha creati. Date le loro caratteristiche possono essere implementati su qualunque SO: lambiente tipico per lUser-Level la JVM

Stati di un thread
Come i processi, anche un thread durante il ciclo di vita pu avere diversi stati. Inoltre la vita di un thread legata a quella del processo che li genera dal momento che se un processo termina allora terminano anche tutti i suoi thread: esso risulta invece indipendente durante la vita del processo, cio evolve senza considerare che il processo sia in esecuzione oppure in attesa Segue il diagramma sul ciclo di vita dei thread, nel quale le transizioni sotto il controllo del sistema vengono indicate in blu mentre quelle effettuate da istruzioni, ovvero dove il controllo del programma, in verde

Idle: prima di essere avviato

Dead: terminate le sue istruzioni Blocked: in attesa di completare lI/O Idle start Ready

Running: in esecuzione
Ready: pronto ma in attesa della CPU

notify ()

notify All() I/O done Quando finito Running

richiesta I/O Blocked stop () Blocked: in attesa di I/O Waiting: in attesa di un evento wait ()

Dispatch

Attesa finita sleep () Sleeping

Waiting

Dead

Sleeping: sospeso un periodo

Un thread viene detto Idle quando non ancora avviato e viene posto nello stato di Ready dove condivide una apposita coda con tutti i thread e i processi che attendono la CPU, gestiti dalle diverse politiche di scheduling, alternando Running e Ready Dallesecuzione passa allo stato Blocked in caso di richieste di operazioni I/O e nello stato di Waiting quando esegue chiamate bloccanti che ne causano la sospensione: non appena la causa del blocco viene rimossa (p.e. con dati dallHD) il thread ritorna nello stato Ready. Dallo stato di Running pu passare anche allo stato Sleeping, che uno stato in cui effettua cicli di attesa per poi essere rimesso in coda tra i processi. Dallo stato di Running un thread pu passare allo stato di Dead, qualora abbia eseguito tutte le proprie istruzioni Se un thread si blocca per richiesta di I/O e passa in Bloched, il sistema potrebbe decidere di eseguire un altro thread dello stesso processo oppure un thread di altri processi: se User-Level (thread Java) non vede i thread ed esegue un altro processo; se KernelLevel (thread C) viene gestito lo scheduling a livello thread