Come prevenire i thread da fame in C ++ 11

Mi chiedo solo se esiste un codice di blocco in C ++ 11 che impedisce i thread di inedia.

Ho un sacco di thread che competono per un mutex. Ora, il mio problema è che il thread che sta lasciando una sezione critica inizia immediatamente a competere per lo stesso mutex e la maggior parte delle volte vince. Quindi altri thread in attesa sul mutex stanno morendo di fame.

Non voglio lasciare che il thread, lasciando una sezione critica, dorma per una quantità minima di tempo per dare ad altri thread la possibilità di bloccare il mutex.

Ho pensato che ci dovrebbe essere qualche parametro che consentirebbe un corretto lock per i thread in attesa sul mutex ma non sono stato in grado di trovare alcuna soluzione appropriata.

Bene, ho trovato la funzione std :: this_thread :: yield (), che suppone di riprogrammare l’ordine dell’esecuzione dei thread, ma è solo un suggerimento per il thread del programma di pianificazione e dipende dall’implementazione del thread dello scheduler se riprogramma i thread o meno.

Esiste un modo per fornire un criterio di blocco corretto per i thread che attendono lo stesso mutex in C ++ 11? Quali sono le solite strategie?

Grazie

Questa è una ottimizzazione comune nei mutex progettata per evitare di sprecare attività di commutazione del tempo quando lo stesso thread può riprendere il mutex. Se il thread corrente ha ancora del tempo nel suo intervallo di tempo, si ottiene un throughput maggiore in termini di istruzioni utente-eseguite al secondo, lasciandolo prendere il mutex invece di sospenderlo e passare a un altro thread (che probabilmente causa un grande ricarica delle linee della cache e vari altri ritardi).

Se si ha così tanto conflitto su un mutex che questo è un problema, allora la progettazione dell’applicazione è sbagliata. Hai tutti questi thread bloccati su un mutex, e quindi non stai facendo nulla: probabilmente stai meglio senza tanti thread.

Dovresti progettare la tua applicazione in modo che se più thread competono per un mutex, non importa quale thread ottiene il lock. La contesa diretta dovrebbe anche essere una cosa rara, in particolare la contesa diretta con molti thread.

L’unica situazione in cui posso pensare che questo sia uno scenario OK è dove ogni thread è in attesa su una variabile di condizione, che viene poi trasmessa per svegliarli tutti. Ogni thread quindi contenderà per il mutex, ma se lo fai bene allora dovrebbero fare tutti un rapido controllo che questa non è una scia spuria e quindi rilasciare il mutex. Anche in questo caso, si parla di una situazione di “bestiame tonante”, e non è l’ideale, proprio perché serializza tutti questi fili.