Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-01 15:41:50

We had some interesting discussions going on about a thread library 
for boost for a while.  However, the subject seems to have died, 
which I find to be very unfortunate.  There's a lot of interest in a 
good C++ thread library, with interesting discussions going on in 
several places online.  So, I'm going to try and regenerate some 
debate on here by discussing my own thoughts.  I should mention that 
I'm familiar with threaded programming, having implemented some 
thread libraries myself and done a fair amount of threaded coding, 
but I'm far from an expert so a lot of what I have to say may be 
obvious or even not a good idea.

Someone else wanted to start with the primitive types that should be 
defined, so I'll start there.  The primitives I think that should be 
defined as class objects:

thread
mutex
semaphore
condition

That's it.  No more, no less.  Let me address each and why I think 
they should be accounted for.  The thread class is obvious... you 
need some representation for a running thread in order to control 
various aspects of the thread.  The mutex is the fundamental 
synchronization object.  In fact, with a mutex it's possible to 
develop any other thread synchronization object, so one could argue 
for this being the only type needed by the library.  However, for any 
real program there will be a need for other synchronization types and 
it's best to not have to keep reinventing the wheel each time.  So, a 
semaphore is a good primitive to include, since it allows for 
synchronization of multiple threads.  The condition is also a good 
candidate, since it allows for simple notification of events between 
threads.

The types I've left out include events, gates and read/write locks 
(probably others as well, though these are all that I can think of).  
Events are too tricky for general use, IMHO, and I've come to this 
opinion despite being a Windows programmer where we have events 
instead of conditions.  Events and conditions generally serve the 
same purpose, but the condition is simply easier to use and more 
versatile.  Gates... well, I don't have any real experience with them 
to comment authoritatively, but it seems to me like a mutex will 
suffice in it's place most (all?) of the time.  Read/write locks are 
nice, but their use is honestly restricted enough in my own 
experience to be left out.  Besides, they aren't hard to build from 
the other primitives I've included.

If nothing else, it seems that these types would be a good starting 
point for further discussion.  There's a lot of discussion that can 
be applied to the interface of each of these types, and possibly such 
discussion would lead to a refinement of the types to be included.  
There's also a few "utility" objects that should be discussed for 
inclusion in a threading library, such as shared memory, atomic 
integers (integers with atomic mathematical operations) and thread 
local storage, but for now it seems safe to me to leave them out.

Comments?