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.

### 784. unique_lock::release

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* release disown();
>        ...
>     };

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

>     mutex_type *release disown();