|
Boost : |
From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-08 15:46:16
--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: William Kempf <sirwillard_at_m...>
> I agree that throwing an exception is a much safer interface, and
> reasonably clean to use. I don't see that this
>
> try {
> mutex::try_lock tlk(mx);
> cond.wait(tlk, ...);
> DoSomethingInteresting();
> } catch (failed_try) {
> DoSomethingElse();
> }
>
> is any harder to write than this
>
> mutex::try_lock tlk(mx);
> if (tlk)
> {
> cond.wait(tlk, ...);
> DoSomethingInteresting();
> } else {
> DoSomethingElse();
> }
The real issue is performance. Exceptions are expensive, and the
main reason to use a try lock is to try and eke out the best possible
performance (there's other reasons, yes). It might be nice to have
multiple types of try locks, compile time options on behavior, or to
make use of the nothrow concept of new. We've been down this road
before, so I don't expect a concesus of opinion on this one yet, but
I bet we come back to this at some point.
> And as an aside, here is another interesting discussion of
> what is broken about the Java thread model:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr.html
>
> My favorite quote:
>
> Chapter 17 of the Java Language Specification (and Chapter 8
> of the Java Virtual Machine Specification) describe the
> semantics of threads and locks, as well as related features
> such as volatile variables. Unfortunately, that specification
> has been found to be very hard to understand and has many
> subtle, unintended implications. It is unclear if anyone
> actually understands the entire specification and its
> implications.
>
> I am glad to see us working so hard to do a better job, however
> frustrating the discussion can sometimes get.
Amen!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk