Re: [boost] Threading equivalent to GOTO

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-08 08:49:27

In message <4.3.2.7.2.20000808083824.00b36ef8_at_[hidden]>, Beman
Dawes <beman_at_[hidden]> writes
[...]
>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)

As we do not have the luxury of having a compiler convert our high-level
concepts automatically into lower level synch primitives -- the way that
structured control flow maps down to jump statements -- it seems that
mutex or mutex-like synch primitives are a necessary library primitive.
Or rather, if we do have the luxury, then it falls outside the scope of
what Boost aims to do with C++ libraries ;-)

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

Yup, I would agree with pretty much all that is said in this. Perhaps a
reader/writer and resource-acquisition model based around const? There's
an example of this in the paper, Executing Around Sequences, that I
posted a while back. If anyone's interested, I could expand that
synchronization model into a fuller library. Thread abstractions are
notably missing from that paper (not of relevance to the paper, so I
shrouded it in an SEP field), but I would presume we would base them
around function objects.

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

Perhaps we should be approaching this in an STL style, following the
suggestions made on this list, drawing up sets of reqs: Mutex covers
three levels of synchronisation behaviour, each more specific than the
previous, ie Semaphore, Ownership Mutex, and Recursive Mutex (or
something along those lines).

This could perhaps be taken further to incorporate the reader/writer
aspect wrt qualification.

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

Couldn't agree more. Sometimes people make the mistake of pretending it
isn't there or attempting to make it completely transparent. As a result
many lead themselves into error or oversimplified programming models (eg
as proposed by Bertrand Meyer in OOSC 2e).
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________