This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 33.6.5.4.4 [thread.lock.unique.mod] Status: NAD Submitter: Constantine Sapuntzakis Opened: 2008-02-02 Last modified: 2016-01-28
Priority: Not Prioritized
View all issues with NAD status.
Discussion:
unique_lock::release
will probably lead to many mistakes where people
call release
instead of unlock
. I just coded such a mistake using the
boost pre-1.35 threads library last week.
In many threading libraries, a call with release
in it unlocks the
lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
I don't call unique_lock::lock
much at all, so I don't get to see the
symmetry between ::lock
and ::unlock
. I usually use the constructor to
lock the mutex. So I'm left to remember whether to call release
or
unlock
during the few times I need to release the mutex before the scope
ends. If I get it wrong, the compiler doesn't warn me.
An alternative name for release may be disown
.
This might be a rare case where usability is hurt by consistency with
the rest of the C++ standard (e.g. std::auto_ptr::release
).
[ Bellevue: ]
Change a name from release to disown. However prior art uses the release name. Compatibility with prior art is more important that any possible benefit such a change might make. We do not see the benefit for changing. NAD
Proposed resolution:
Change the synopsis in 33.6.5.4 [thread.lock.unique]:
template <class Mutex> class unique_lock { public: ... mutex_type*releasedisown(); ... };
Change 33.6.5.4.4 [thread.lock.unique.mod]:
mutex_type *releasedisown();