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: 32.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 32.6.5.4 [thread.lock.unique]:
template <class Mutex>
class unique_lock
{
public:
...
mutex_type* release disown();
...
};
Change 32.6.5.4.4 [thread.lock.unique.mod]:
mutex_type *releasedisown();