Kann thread versuchen, std :: lock [_unique] ein std :: shared_mutex verhungern von Threads std :: lock_shared aufrufen?

Question

Eine Frage bezüglich std::shared_mutex und die Übernahme von unique_lock.

Angenommen, es gibt 3 Themen:

• 2 Leser (versuchen zu lock_shared() die std::shared_mutex) und
• 1 Schreiber (bis lock[_unique]() die std::shared_mutex versuchen)

Ist es möglich, dass die Schriftsteller versucht zu lock[_unique]() wäre verhungert? Zum Beispiel: Mindestens ein Leser besitzt eine std::shared_lock, und lock[_unique]() kann niemals erfolgreich sein.

Mehr oder weniger: würde lock[_unique]() auf einem std::shared_mutex blockieren alle Versuche, lock_shared() es weiter zu machen?

---

(ziemlich sicher, dass boost::upgrade_lock könnte hier arbeiten, aber ich würde gerne wissen, ob eine Garantie für bare std::unique_lock auf einem std::shared_mutex es)

Answer 1

Mehr oder weniger: würde lock[_unique]() auf einem std::shared_mutex Block jeden Versuche, lock_shared() es weiter zu machen?

Der Standard ist nicht festgelegt, ob das geschehen soll oder nicht, heißt es nur:

Effekte: Blockiert den aufrufenden Thread, bis Miteigentum des Mutex kann für den anrufenden Faden erhalten werden .

So bleibt es der Implementierung überlassen, ob spätere Leser hinter ausstehende Autoren warten oder nicht.

Wenn die Implementierung Writer-Hunger verhindern will, muss möglicherweise ein Writer-Waiting-Flag gesetzt werden, wenn ein Thread versucht, eine eindeutige Sperre zu erhalten, sodass spätere Versuche, eine gemeinsame Sperre zu erhalten, blockieren und warten hinter dem einzigartigen Schließfach. In der N2406-Referenzimplementierung ist dies das write_entered_-Bit im state-Element.