Can thread che tenta di std :: lock [_unique] uno std :: shared_mutex essere affamato dai thread che chiamano std :: lock_shared?

Question

Una domanda riguardante std::shared_mutex e l'acquisizione di unique_lock.

Si supponga ci sono 3 fili:

• 2 lettori (che cercano di lock_shared() la std::shared_mutex), e
• 1 scrittore (cercando di lock[_unique]() la std::shared_mutex)

E 'possibile che il lo scrittore che prova a lock[_unique]() sarebbe morto di fame? Ad es .: in ogni momento almeno un lettore possiede uno std::shared_lock e lock[_unique]() non può mai avere successo.

Più o meno: sarebbe lock[_unique]() su un std::shared_mutex bloccare qualsiasi tentativo di ulteriore lock_shared() esso?

---

(abbastanza sicuro boost::upgrade_lock potrebbe lavorare qui, ma mi piacerebbe sapere se c'è alcuna garanzia per la nuda std::unique_lock su un std::shared_mutex)

Answer 1

Più o meno: avrebbe lock[_unique]() su un blocco std::shared_mutex qualsiasi tenta di ulteriore lock_shared() esso?

La norma non specifica se ciò dovesse accadere o no, si dice solo:

Effetti: Blocca il thread chiamante fino a quando la proprietà condivisa del mutex può essere ottenuto per il thread chiamante .

Così è lasciato all'implementazione se fa aspettare i lettori successivi dietro scrittori pendenti o meno.

Se la realizzazione vuole impedire scrittore fame allora potrebbe bisogno di avere uno "scrittore attesa" bandiera che viene impostato quando un thread tenta di ottenere un blocco unico, in modo che i tentativi più tardi per ottenere un blocco condiviso bloccherà, in attesa dietro l'armadietto unico. Nell'implementazione di riferimento N2406 questo è il bit write_entered_ nel membro state.