Il kernel di Linux è a conoscenza di pthreads nello spazio degli indirizzi degli utenti (che non penso sia .. ma non ho trovato alcuna informazione a riguardo). Come cambia il puntatore Instruction quando si verifica il cambio di thread .. ??In che modo la suddivisione del tempo è divisa tra i pthread in un processo?
1) Il kernel non conosce i thread a livello utente. Tuttavia, NPTL non è il livello utente
2) Questa è una domanda molto ampia. Si dovrebbe guardare un libro del sistema operativo. Andrà in profondità su quel problema e su tutti gli altri coinvolti in un cambio di contesto.
hey Grazie !! AFAIK, i libri OS coprono il cambio di contesto del processo. ma mi chiedevo, come è il tempo di gestire la gestione tra i thread in corso .. se il kernel non è a conoscenza del thread, è qualcosa come in parte, le attivazioni dello scheduler? se non come è il processo, in grado di gestire e prenotare mantenere i thread. e più mi sento sopra, questo è più relativo alla programmazione a livello di utente .. quindi, ponete la domanda qui .. – SpinLocked
Se siete interessati a sapere come fa Linux queste cose, date un'occhiata a Linux Kernel Development di Robert Love. Copre molto, ma è abbastanza accessibile. Godere. – Avi
Bene il kernel Linux non conosce i thread utente (pthread lo fa in userspace, inoltre il kernel non si preoccupa veramente di loro eccetto che ha solo bisogno di sapere cosa pianificare).
Il puntatore dell'istruzione viene modificato nel kernel durante il cosiddetto interruttore di contesto. Durante questo passaggio il kernel chiede essenzialmente al programmatore quali sono i prossimi? lo schedulatore gli consegnerà un task_struct che contiene tutte le informazioni sul thread e il gestore di interrupt per un commutatore di contesto andrà avanti e imposterà i valori sulla CPU di conseguenza (tabelle di pagina, puntatore di istruzioni, ecc ...) e quando quel codice è fatto, la CPU inizia semplicemente ad eseguire da lì.
Quindi è essenziale dire che .. un thread ottiene una fetta a tempo pieno, il processo è stato assegnato con? e non c'è una divisione temporale che divide i thread con un processo? – SpinLocked
@SpinLocked Il kernel non si cura se si tratta di un processo o thread (in realtà non fa distinzione) a cui importa solo la priorità (quantità di tempo per dare il thread) e se è programmabile o meno (in attesa di I/O o qualcosa del genere). –
Grazie. Probabilmente ho dichiarato male la domanda. Scuse. intendo conoscere il lavoro di programmazione a livello di thread. È una semplice suddivisione in termini di tempo per la mappatura dei thread o, c'è qualche intelligenza a livello di processo, che dà ad ogni thread una condivisione del tempo. – SpinLocked
Il NPTL nativo (libreria di thread di posix nativo) utilizzato in pthreads di mappe Linux per "processi che condividono risorse e quindi sembrano thread" nel kernel. In questo modo, lo scheduler del kernel controlla direttamente la programmazione dei pthread.
Un "interruttore di pthread" viene eseguito dallo stesso codice esatto (nel kernel) che gestisce gli interruttori di processo. Semplificato, sarebbe qualcosa come "Memorizza lo stato del processo precedente, se il processo successivo utilizza uno spazio di indirizzo virtuale diverso, quindi cambia gli spazi degli indirizzi virtuali, carica il successivo stato del processo;" (dove "stato del processo" include il puntatore di istruzioni per il processo/thread).
grazie ricevuto alcune informazioni. potresti citare qualche fonte per ulteriori informazioni .. – SpinLocked
È proprio come Linux ha sempre fatto i thread. Ho trovato alcuni riferimenti però. 1) scorri fino a "5 Linux" all'indirizzo http://www.icir.org/gregor/tools/pthread-scheduling.html. 2) scorrere verso "Implementazioni Linux di thread POSIX" all'indirizzo http://linux.die.net/man/7/pthreads. – Brendan
Mentre non vi è alcuna differenza di pianificazione tra thread e processi, è possibile raggruppare thread/processi in gruppi di controllo, ciascuno dei quali verrà trattato dallo scheduler come "entità contabile", vale a dire addebiterà l'intero gruppo di controllo per il Tempo CPU, quindi se si raggruppa, ad es una invocazione di esperti (che crea molti thread), i rimanenti gruppi di controllo otterranno una parte più equa del tempo della CPU. – ninjalj