[Boost-bugs] [Boost C++ Libraries] #12350: shared_mutex (pthreads) unlocked to early in unlock_shared()

Subject: [Boost-bugs] [Boost C++ Libraries] #12350: shared_mutex (pthreads) unlocked to early in unlock_shared()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2016-07-25 15:40:41

#12350: shared_mutex (pthreads) unlocked to early in unlock_shared()
-------------------------------------------------+-------------------------
 Reporter:  Maximilian Czerny                    |      Owner:  anthonyw
  <maximilian.czerny@…>                          |     Status:  new
     Type:  Bugs                                 |  Component:  thread
Milestone:  To Be Determined                     |   Severity:  Problem
  Version:  Boost 1.61.0                         |
 Keywords:                                       |
-------------------------------------------------+-------------------------
 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).

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/12350>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.