Filettature preventive Vs Filettature non preventive

Question

Qualcuno può spiegare la differenza tra il modello di threading preemptive e il modello di threading non preventivo?

Come per la mia comprensione:

• non preventiva modello di thread: volta un thread avviato, non può essere interrotto o il controllo non può essere trasferito ad altri thread finché il filo ha completato il suo compito.
• Modello di filettatura preventiva: Il runtime può entrare e passare manualmente da un thread a un altro in qualsiasi momento. I thread con priorità più alta hanno la precedenza sui thread con priorità più bassa.

Qualcuno può per favore:

1. Spiegate se la comprensione è corretta.
2. Spiegare i vantaggi e gli svantaggi di entrambi i modelli.
3. Un esempio di quando utilizzare ciò che sarà veramente utile.
4. Se creo un thread in Linux (system v o Pthread) senza menzionare alcuna opzione (ce ne sono ??) per impostazione predefinita il modello di threading utilizzato è il modello di threading preventivo?

Answer 1

1. No, la tua comprensione non è del tutto corretta. I thread non preventivi (in genere cooperativi) generano manualmente il controllo per consentire l'esecuzione di altri thread prima che siano terminati (anche se è a tale thread chiamare yield() (o qualsiasi altra cosa) per farlo accadere
2. La filettatura preventiva è più semplice.
3. Normalmente utilizzare preventiva Se si trova che il progetto ha un sacco di overhead di commutazione del thread, thread cooperativi sarebbe una possibile ottimizzazione. In molti (la maggior parte?) situazioni, questo sarà un investimento abbastanza grande con payoff minimo però.
4. Sì, per impostazione predefinita si otterrebbe il thread preventivo, sebbene se si cerchi il pacchetto CThreads, esso supporta il threading cooperativo. numero sufficiente di persone Pochi (ora) vogliono le discussioni cooperative che io non sono sicuro che è stato aggiornato nel corso dell'ultimo decennio, anche se ...

Answer 2

I thread non preventivi vengono anche chiamati thread cooperativi. Un esempio di questi è POE (Perl). Un altro esempio è il classico Mac OS (prima di OS X). I thread cooperativi hanno l'uso esclusivo della CPU fino a quando non lo abbandonano. Quindi lo scheduler preleva un altro thread da eseguire.

I thread preventivi possono rinunciare volontariamente alla CPU come quelli cooperativi, ma quando non lo fanno, verranno presi da loro e lo scheduler avvierà un altro thread. POSIX & I thread SysV rientrano in questa categoria.

I grandi vantaggi dei thread cooperativi sono una maggiore efficienza (su macchine single-core, almeno) e una gestione più semplice della concorrenza: esiste solo quando si cede il controllo, quindi non è richiesto il blocco.

grandi vantaggi di discussioni preventive sono meglio tolleranza di errore: un singolo filo avendo cedere non arresta tutti gli altri thread da eseguire. Inoltre, normalmente funziona meglio su macchine multi-core, poiché più thread vengono eseguiti contemporaneamente. Infine, non devi preoccuparti di assicurarti di cedere costantemente. Ciò può essere davvero fastidioso all'interno, ad es. Un ciclo pesante di crunch numerico.

È possibile combinarli, ovviamente. Un singolo thread preemptive può avere molti thread cooperativi in ​​esecuzione al suo interno.

Answer 3

Se si utilizza non-preemptive ciò non significa che il processo non rende il contesto cambia quando il processo è in attesa di I/O. Il dispatcher sceglierà un altro processo in base al modello di pianificazione. In questo modello dobbiamo fidarci del processo.

non preemptive:

commutazione di contesto 1.Less = meno sopra testa che può essere sensibile modello non-preemptive

2.It facile da gestire in quanto può essere gestito sulla single-core

preventiva:

Vantaggio:

1.In questo modello abbiamo prioritario che può aiutarci ad avere un maggiore controllo sul processo di esecuzione

2.We può vedere la concorrenza meglio

3.we in grado di gestire un sistema di chiamata senza bloccare tutto il sistema

Svantaggio:

1.We bisogno algoritmo complesso di bloccaggio e abbiamo problema sezione critica dovrebbe essere gestito

2. Spesso un sovraccarico che dovremmo pagare