Threading equivalent to GOTO

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).