shared_mutex (pthreads) unlocked too early in unlock_shared()

[Maximilian Czerny <maximilian.czerny@…>]

Hej, I experienced some odd behaviour in the unlock_shared() function of the shared_mutex in the pthreads implementation. I wanted to do the following: There is a class node that has a shared_mutex with which I implemented optimistic locking for a tree data structure. A node can be deleted if its parent and the node itself is locked (exclusive) by the current thread. The problem with that boils down to the following order of two threads (R - reader, W - writer) operating on a node in this way:

1. R successfully calls lock_shared() on a node
2. W (which holds a shared lock) wants to change the node

• try_unlock_shared_and_lock_upgrade()
• unlock_upgrade_and_lock() puts W to sleep as R still holds a shared lock

3. R calls unlock_shared() and internally does (thread/pthreads/shared_mutex.hpp void unlock_shared()):

• it gets the unique_lock to modify the state
• it decreases the number of shared locks to 0
• it therefore notifies R and unlocks the unique_lock

4. W modifies the node and deletes it
5. R crashes in release_waiters as it now accesses deleted memory

I fixed this by removing the two premature unlocks (lk.unlock()) but I am not sure if that is valid for all applications. That means that state changes are ownly possible after all operations are actually done (when the unique_lock goes out of scope).

[viboes]

Sorry for been late. I will take a look at asap.

[viboes]

Good catch.

I'll commit the change soon.

[viboes]

​https://github.com/boostorg/thread/commit/e34d343c12e7b9d53309a1866a409a7284f88460