784. unique_lock::release

Section: 33.4.4.3.3 [thread.lock.unique.mod] Status: NAD Submitter: Constantine Sapuntzakis Opened: 2008-02-02 Last modified: 2016-02-10

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.4.4.3 [thread.lock.unique]:

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

Change 33.4.4.3.3 [thread.lock.unique.mod]:

mutex_type *release disown();