Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 2000-08-08 07:45:33


I posted a query to comp.programming.threads:

> There is discussion on the boost mailing list (www.boost.org) of design
> issues for a possible C++ threading library suitable for eventual
> inclusion in the C++ standard library.
>
> Some suggest starting the design with very low-level primitives, and
> then using these to build higher-level features. But like a goto
> statement in programming languages, some low-level features can be
> error-prone and so should not always be exposed to users even if present
> in the underlying implementation.
>
> So here is a question where comp.programming.threads readers probably
> have valuable insights:
>
> What features should be excluded from a threading library because they
> are known to be error-prone or otherwise dangerous? What are the
> threading equivalents of goto statements?

The first reply is from Frank Gerlach <Frank.Gerlach_at_[hidden]>:

Some people say semaphores are the concurrent-processing equivalent of
GOTO.... Still, semaphores are very useful and sometimes even
indispensable. (IMO goto is sometimes also a good construct, e.g. in state
machines)

A useful construct might be ReaderBlock and WriterBlock classes, which take
a ReadWriteMutex as a constructor argument and can be used similar to the
synchronize() construct of java. Those classes lock the mutex in the
constructor and unlock it in their destructor, avoiding explicit unlocking
AND exception handling easy. The latter is especially important, as I
cannot think of an elegant way to unlock a mutex in case an exception is
thrown,
which will be handled in a calling method.

In general, one could provide a list of synchronization constructs in
ascending order of complexity/danger for novice users. The
Reader/Writerblock is quite harmless, even if you do not think about its
consequences. Still, you can easily deadlock your program by using two
mutexes and acquiring them in opposite order.

My feeling is that concurrent programming contains inherent complexity,
which cannot be eliminated.

As a final input, automatic deadlock detection in debug mode would be a
simple, but great feature for both C++ libs and Java VMs (unfortunately SUN
does not provide this in their VMs).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk