Re: [boost] Design and documentation of Boost.Threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 10:07:05

From: "Alexander Terekhov" <terekhov_at_[hidden]>
> [...]
> > recursive_mutex.html
> > --------------------
> [...]
> > scoped_lock.html:
> > -----------------
> [...]
>
> http://groups.google.com/groups?as_umsgid=361B4FBB.D396A5DB%40zko.dec.com
> (that is why I dislike both)

"Right. It's a "syntactic shorthand" -- nothing more. And, as I said,
automatically unlocking a mutex on an exception isn't necessarily a favor.
You
still need to be agressively aware of broken invariants, and those need to
be
repaired before the mutex is unlocked. The language can't help you with
this,
because it doesn't know anything about invariants or even shared data.
That's
nothing new -- anyone using C and POSIX threads is familiar with those
problems. The point is that Java implies that it handles this for you, while
it actually leaves you entirely on your own."

True but modern exception safe C++ code either preserves invariants on
exception, or makes calling methods (apart from the destructor or where
explicitly specified) undefined after an exception, even in single-threaded
programs. So scoped_lock is correct to release the lock on exception.

--
Peter Dimov
Multi Media Ltd.