La migliore pratica non è quella di effettuare il polling ... ma il polling non si verifica comunque internamente quando un thread chiama wait ()?

Supponiamo che abbiamo un thread che vuole verificare quando un altro thread ha terminato il suo compito. Ho letto che dovremmo chiamare una funzione di tipo wait () che farà aspettare questo thread fino a quando non riceve una notifica che l'altro thread è finito. E questo è positivo perché significa che non stiamo eseguendo sondaggi costosi.

Ma il polling non sta avvenendo internamente a un livello inferiore comunque? Cioè se facciamo attendere il thread () il kernal non sta eseguendo comunque il polling per controllare quando l'altro thread è finito in modo che possa quindi notificare il primo thread?

Presumo che mi stia perdendo qualcosa qui, qualcuno può illuminarmi?

parallelism multithreading locks

— CSSS
fonte

Il sistema operativo fornisce alcune primitive per questo tipo di comunicazione tra processi che non richiedono il polling.

Se il processo A è in attesa su mutex M, il sistema operativo sa che A non può essere eseguito e lo mette da parte in un secchio di processi in attesa che qualcosa accada. Quando il processo che tiene M lo rilascia, il sistema operativo esamina l'elenco dei processi che lo attendono. Il primo processo nell'elenco, forse A, viene rimosso dal bucket inattivo e inserito nella coda di esecuzione . La prossima volta che A ottiene una fascia oraria, l'attesa () che chiamerà tornerà e il programma continua.

— Blrfl
fonte

quindi in un certo senso è polling ma a livello di sistema operativo?

— tgkprog,

No @tgkprog, non si tratta di polling, poiché il processo di attesa non è pianificato per l'esecuzione fino a quando il sistema operativo o un altro processo non rilasciano il mutex. Un processo di polling continuerebbe a competere nella programmazione della CPU al fine di verificare se dovesse smettere di aspettare. Un processo di polling di questo tipo può bruciare una parte sostanziale del tempo della CPU mentre attende.

— joshp

intendevo che il processo del sistema operativo eseguiva il polling dello stato del mutex. anche se sono sicuro che sia ottimizzato e migliore di tutto ciò che potremmo fare. probabilmente viene eseguito come parte dello scheduler.

— tgkprog,

@tgkprog: il sistema operativo non presta un po 'di attenzione a quello che sta succedendo con un mutex fino a quando il processo che lo tiene non lo rilascia o termina. Uno di questi eventi farà sì che il sistema operativo passi il blocco mutex a qualunque processo sia prima nella lista di attesa e contrassegnerà quel processo come eseguibile. Non ci sono sondaggi coinvolti, solo la risposta a un evento. Tutto ciò che joshp ha detto è incluso come riferimento. :-)

— Blrfl

@csss: praticamente. I processi possono terminare volontariamente (ad es. _exit(2)Invocando sistemi POSIX-y) o involontariamente (ad es. Un errore come un divisione per zero genera un interrupt o qualcos'altro chiama kill(2)). In entrambi i casi, il controllo viene esplicitamente restituito al sistema operativo, che sa quale processo era in esecuzione o deve essere interrotto. Il compito di terminare un processo include la liberazione delle sue risorse, inclusi i mutex. Se un mutex fosse trattenuto dal processo ormai morto, il sistema operativo lo rilascerà. Se il processo era nella lista di attesa del mutex, verrà rimosso.

— Blrfl