Title
unique_lock::release
Status
nad
Section
[thread.lock.unique.mod]
Submitter
Constantine Sapuntzakis

Created on 2008-02-02.00:00:00 last changed 171 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

Change the synopsis in [thread.lock.unique]:

template <class Mutex> 
class unique_lock 
{ 
public:
   ...
   mutex_type* release disown();
   ...
};

Change [thread.lock.unique.mod]:

mutex_type *release disown();
Date: 2010-10-21.18:28:33

[ 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

Date: 2008-02-02.00:00:00

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).

History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg3764
2010-10-21 18:28:33adminsetmessages: + msg3763
2008-02-02 00:00:00admincreate