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.
Section: 33.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" 33.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 33.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]