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?