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.6.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.6.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.6.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]