Boost.Threads - 'lock' name (was Re: Boost.Thread

From: williamkempf_at_[hidden]
Date: 2001-07-19 08:54:33

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > So long as we have a "lock" concept...
> 
> what you currently have is the concept known
> to everyone and his dog as SCOPED LOCKING.

Scoped Locking is the name of the pattern, not the concept.  If we 
follow the name of the pattern exactly the name of the concept would 
be scoped_lock, which frankly isn't much different from auto_lock 
which I suggested as better than any of the names you gave.  However, 
I suppose for numerous reasons scoped_lock would be better yet.  My 
problem here, though, is that the nebulous complaint you have against 
the shorter name "lock" is going to exist with "scoped_lock" as 
well.  There's a conceptual difference between this sort of "lock" 
and a "spinlock".

> which is simply a convenient way to deal with
> (acq/rel) LOCKS (mutexes, semaphores,
> read/write locks, spinlocks,...).

A mutex is not a lock, though.  It can be LOCKED, but that's not the 
same thing.  If you want to look at this from an English language 
view point, the name "lock" doesn't really fit either concept 
perfectly.  However, I still think it's an intuitive name for the 
Scoped Locking object.
 
> e.g. POSA2, Pg. 325:
> 
> "Scoped Locking C++ idiom ensures that
>  a *LOCK* is acquired when control enters
>  a scope and released automatically
>  when control leaves the scope,
>  regardless of the return path from
>  the scope."

Yes, but the word "LOCK" that you so carefully highlight here does 
not refer to the mutex, but to the lock that you acquire on the 
mutex.  This is like saying "a *HANDLE* that is acquired when a file 
is opened".
 
> note that this concept alone is somewhat
> less robust/helpful than POSIX cancellation
> cleanup handlers; releasing the lock with
> associated data left in broken state is not
> really helpful.. btw, that is why win32
> ABANDONED mutex state is practically
> useless and is rather brain damaged
> concept, IMHO.

You can't compare these two.  An abandoned mutex is in a very 
different state then the mutex that's been automatically released.  
In fact, there is exactly ZERO difference between the program stack 
cleaning up resources and your POSIX clean up stack cleaning up 
resources.  Your argument about data being left in a "broken state" 
applies equally to both, and are handled by user code in either a 
clean up handler or destructor/catch block.  It's just as easy to do 
this wrong with both styles.  The reason for the POSIX style clean up 
stacks is simply because C does not have the concept of destructors 
and/or catch blocks so they had to add an artificial method of doing 
the same thing.

Bill Kempf