在共享模式下锁定的std :: shared_mutex上调用unlock

Question

C++17 introduces the std::shared_mutex type. I have been looking at the documentation over on CppReference with a particular interest for cases that produce undefined behavior.

While reading through both unlock methods (one for releasing exclusive ownership, one for releasing shared ownership), I've noticed the documentation is a little vague on one occasion.

For std::shared_mutex::unlock_shared , the documentation states (emphasis mine):

The mutex must be locked by the current thread of execution in shared mode , otherwise, the behavior is undefined.

It is clearly indicated that a call to unlock_shared must be preceded by a call to lock_shared as that is the only way to lock the mutex in shared mode.

For std::shared_mutex::unlock , the documentation states:

The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined.

There is no mention of the level of access the current thread of execution must hold before calling unlock . This made me wonder if it is also capable of releasing shared ownership as well as exclusive ownership.

My question: is it undefined behavior to release shared ownership of a std::shared_mutex with a call to unlock instead of unlock_shared ?

If possible, I'd like a quote from the C++ standard that explicitly confirms or denies undefined behavior in the aforementioned scenario.

Answer 1

Per [thread.mutex.requirements.mutex] we have

The expression m.unlock() shall be well-formed and have the following semantics:

Requires : The calling thread shall own the mutex.

Effects : Releases the calling thread's ownership of the mutex.

Return type: void.

Synchronization : This operation synchronizes with subsequent lock operations that obtain ownership on the same object.

Throws : Nothing.

So, as long as the thread owns the mutex ,whether it is in shared mode or not, unlock will release the threads ownership of the mutex.

Answer 2

I didn't go through the standard to verify what exactly it says, but the original proposal clearly states that lock / unlock and lock_shared / unlock_shared calls should be paired:

shared_mutex  | Semantics
--------------+---------------------------------------------
lock          | Lock the mutex in unique ownership mode
unlock        | unlock the mutex from unique ownership mode
lock_shared   | Lock the mutex in shared ownership mode
unlock_shared | unlock the mutex from shared ownership mode

It also explicitly states that this separation exists because of how SRWLOCK is implemented on Windows:

Additionally, some operating systems (eg Windows) have different names for unlocking shared vs unlocking unique as well. Use of different names in the C++ API allows for a more efficient binding to such OS API's.

If standard does not mention this somewhere explicitly, it is most likely a defect in the standard. Regardless of where this was intentional, in practice all shared_mutex implementations shipped with MSVC on Windows will not work like that as they require pairing lock-unlock calls properly.

On POSIX systems both unlock and unlock_shared are indeed mapped to a single function pthread_rwlock_unlock , so both are most likely to be equivalent there. This is a side effect that should not be relied upon.

---

On Windows 7 SRWLOCK uses the least significant bit to mark lock as locked by either reader or writer. Function unlock clears that bit, corrupting the lock, while unlock_shared only clears it if the last reader leaves the lock. Following example shows how the lock changes its state:

mtx.lock_shared(); // 0x11 - 1 reader, locked (shared)
mtx.lock_shared(); // 0x21 - 2 readers, locked (shared)
mtx.unlock();      // 0x20 - 2 readers, unlocked (invalid state)
mtx.lock();        // 0x21 - 2 readers, locked (shared)

Final lock is able to acquire the mutex even through there is another reader holding the lock. After that std::shared_mutex is considered to be locked by 2 readers, so more readers can enter the lock. So in the sequence above lock has locked the mutex in shared ownership mode, instead of exclusive as a side effect of misusage.