This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

### 1218. mutex destructor synchronization

Section: 32.5.4 [thread.mutex.requirements] Status: C++11 Submitter: Jeffrey Yasskin Opened: 2009-09-30 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [thread.mutex.requirements].

View all other issues in [thread.mutex.requirements].

View all issues with C++11 status.

Discussion:

If an object `*o` contains a mutex `mu` and a correctly-maintained reference count `c`, is the following code safe?

>     o->mu.lock();
>     bool del = (--(o->c) == 0);
>     o->mu.unlock();
>     if (del) { delete o; }

If the implementation of `mutex::unlock()` can touch the mutex's memory after the moment it becomes free, this wouldn't be safe, and "Construction and destruction of an object of a Mutex type need not be thread-safe" 32.5.4 [thread.mutex.requirements] may imply that it's not safe. Still, it's useful to allow mutexes to guard reference counts, and if it's not allowed, users are likely to write bugs.

[ 2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

Proposed resolution:

- Add a new paragraph after 32.5.4.2.2 [thread.mutex.class] p1:

  > 1 The class `mutex` provides a non-recursive mutex ...

  > [Note: After a thread `A` has called `unlock()`, releasing the mutex, it is possible for another thread `B` to lock the same mutex, observe that it is no longer in use, unlock and destroy it, before thread `A` appears to have returned from its unlock call. Implementations are required to handle such scenarios correctly, as long as thread `A` doesn't access the mutex after the unlock call returns. These cases typically occur when a reference-counted object contains a mutex that is used to protect the reference count. — end note]