Re: [Threads-devel] scoped_lock::release method potentially confusing

From: Anthony Williams (anthony_at_[hidden])
Date: 2008-01-31 06:00:13

Quoting Constantine Sapuntzakis <csapuntz_at_[hidden]>:

> I suggest that scoped_lock::release be either renamed or be hidden from
> easy use. I spent about 45 minutes tracking down a bug in my code where
> I used scoped_lock::release instead of scoped_lock::unlock.
>
> The mistake was due to my experience with other libraries. For example,
> java's concurrency library uses release() instead of unlock(). Win32 API
> is called ReleaseMutex. More generally, the terminology acquire/release
> is often used with synchronization constructs.
>
> The current semantics of scoped_lock::release() are consistent with
> auto_ptr and other C++ idioms. But I think they may still suprise users.

I would be frustrated if I had spent 45 minutes tracking down a bug  
like that, but I don't think the name is problematic in general, and I  
don't think it should be changed.

This is the name used in the thread library being incorporated into  
the next C++ Standard and as you say, it is consistent with auto_ptr  
and other C++ idioms.

Also, the win32 API has Enter/Leave (for critical sections),  
Wait/Release (for Mutexes or semaphores) and Set/Reset (for Events).  
Java has lock/unlock (in java.util.concurrent.locks.Lock) and  
acquire/release (for java.util.concurrent.Semaphore). Raw atomics have  
acquire/release. In each case, the name of the function used to lock  
the synchronization object is tied to the name used to unlock it.

For boost, we use lock/unlock. Release doesn't fit with lock, so must  
mean something else --- in this case, release ownership of the mutex  
without unlocking.

Anthony
-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL