Re: [thread] upgrade_to_unique_lock takes a upgrade_lock, not an upgrade_mutex

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-06-17 19:35:27

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#thread.synchronization.mutex_concepts.upgrade_lockable