Windows e Debian / Red Hat usano la stessa gestione dei thread?

-4

Devo sapere che tipo di gestione dei thread utilizza Windows e Debian / Red Hat nelle loro versioni recenti.

So che erano soliti usare il modello di gestione dei thread da 1 a 1. Usano ancora questo modello fino ad oggi? O l'hanno cambiato?

— Brezza
fonte

modelli completamente diversi.

— Ramhound,

modelli completamente diversi non sono una risposta, sto studiando e ho bisogno di un punto di partenza, risposte vaghe o implicazioni non sono utili.

— Brezza

Ramhound non ha pubblicato una risposta, ma un commento. Non sono sicuro che questa domanda non sia un po 'troppo ampia. Stai cercando riferimenti specifici? In tal caso, ti preghiamo di chiarire che cosa devi sapere esattamente.

— slhck,

Non sono sicuro di cosa stai chiedendo esattamente. I sistemi operativi non hanno davvero modelli di gestione dei thread.

— David Schwartz,

@Hossein - Le risposte vaghe provengono da domande ampie e sconvolgenti. Dire che Windows e Linux usano due diversi modelli di gestione dei thread è una risposta accettabile.

— Ramhound,

Da CProgramming Borad

L'API win32 supporta sia i modelli uno-a-uno che molti-a-molti (rispettivamente nella libreria thread e nella libreria fibra).

Windows 7, come tutta la famiglia NT, supporta l'API win32.

Windows 7 supporta i thread del kernel. Quindi deve essere un modello uno a uno o molti a molti. Ma in realtà è un ibrido che supporta entrambi i modelli. Per impostazione predefinita utilizzerà la pianificazione uno a uno tradizionale, ma a seconda del numero di entità di pianificazione disponibili per il sistema operativo (in base al numero di processori e core), è possibile forzarlo in un numero da molti a molti programmatori. Il sistema operativo stesso non si sposterà mai automaticamente. Devi dirlo esplicitamente a.

Si noti che la versione a 32 bit di Windows 7 non supporta la pianificazione M: N. Solo la versione a 64 bit.

Linux può anche supportare M: N tramite librerie come RIBS2, proprio come farebbe Windows tramite l'API della fibra.

L'ibrido è sempre meglio perché hai un'opzione per ottimizzare la pianificazione dei thread, mentre prima avevi solo una scelta. Ma trarre vantaggio da un programmatore da molti a molti è un'altra questione del tutto. Dipenderà molto dalla tua necessità di un numero molto elevato di thread e da cosa stanno effettivamente facendo. Non conosco i dettagli esatti, dal momento che non sono mai stato coinvolto in progetti ad alte prestazioni con la necessità di creare un numero molto elevato di thread. Comprendo tuttavia che programmare i thread diventa più semplice, ma gestirli diventa più difficile. In particolare, trascorri molto tempo nella fase di test cercando di ottimizzare i tuoi thread su uno scheduler molto più complesso.

Toms Hardware:

Prima di Windows 7, Windows utilizzava una relazione da uno a uno utente con il thread del kernel. Ovviamente era sempre possibile mettere insieme molti programmatori di utenti (questo può essere fatto praticamente in qualsiasi sistema operativo con interruzioni del timer a livello di utente) ma se una chiamata di sistema bloccata su uno dei thread dell'utente si bloccherebbe il thread del kernel e di conseguenza blocca tutti gli altri thread utente sullo stesso scheduler. Naturalmente, un modello molti-a-uno non può trarre vantaggio da SMP.

Con Windows 7, Microsoft ha introdotto il supporto per la pianificazione in modalità utente. Un programma può configurare uno o più thread del kernel come scheduler (uno per processore logico desiderato) e quindi creare un pool di thread in modalità utente da cui questi UMS possono attingere. Il kernel mantiene un elenco di chiamate di sistema in sospeso che consente a UMS di continuare a funzionare senza bloccare il thread del kernel. Questa configurazione può essere utilizzata da molte a una o da molte a molte.

— Brezza
fonte