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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk