On 6/17/22 21:23, Phil Endecott via Boost wrote:
Dear Experts,
boost::upgrade_mutex m;
void f() { boost::upgrade_lock l(m); // read shared state g(); }
void g() { // precondition: upgrade lock held. boost::upgrade_to_unique_lock l(m); // write shared state }
But that's not how it works. The upgrade_to_unique_lock takes the upgrade_lock as its ctor parameter, not the mutex.
Is there a good reason for that? I think all that upgrade_to_unique_lock needs to do is to call m.unlock_upgrade_and_lock() in its ctor and m.unlock_and_lock_upgrade() in its dotr, i.e. it doesn't need to access any state in the upgrade_lock.
Am I missing something?
It is needed to enforce the contract: in order to upgrade to unique lock you must first obtain the upgradeable ownership[1] via upgrade_lock. Internally, upgrade_lock uses lock_upgrade() on the mutex, as opposed to e.g. unique_lock, which uses lock(), or shared_lock, which uses lock_shared(). This lock_upgrade() call may switch the mutex into an upgradeable state that is distinct from the (exclusively or shared) locked state, and this is required by upgrade_to_unique_lock to function. [1]: https://www.boost.org/doc/libs/1_79_0/doc/html/thread/synchronization.html#t...