Boost.Threads: where do we go from here?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-03-16 13:33:34

In past discussions we decided that a threading library presented some 
unique difficulties.

See the Threads Roadmap I presented last October in Toronto: 
http://groups.yahoo.com/group/boost/files/threads/threads_roadmap.htm

The conclusion was that we should to hold a boost threading library to a 
higher standard than usual, because it must face higher hurdles than usual.

Some of those higher standards have already been applied in the design 
process.  Now it is time to look at some of the others:

*  Example applications.  We need these to make sure the design is useful 
in practical problems, to compare to other solutions, and to try to flush 
out issues not yet dealt with.

It seems to me that it would be very useful if examples were implemented by 
someone other than Bill Kempf.  There is nothing like someone other than 
the developer actually using software to identify issues.  Plus that 
spreads the workload.

It also seems to me that it would be useful if the examples were well 
known, and had implementations using other threading packages for 
comparison.  David Butenhof's "Programming with POSIX Threads" identifies 
(chapter 4) three "primary models for threaded programming" and gives 
solutions for each:

   - Pipeline
   - Work crew
   - Client/server

Perhaps others have better suggestions, but these three problems seem to me 
to be about the right size and feel for this sort of experiment.

*  Test framework.  We need to be able to stress this library on both 
single and multiple processor systems for days on end. Again, it would be 
nice if the test developer was someone other that Bill.  The more 
independent the better.  And it would be helpful if it was someone who 
understood how to test this sort of system.  Fiendish is the word that 
comes to mind.  (I can help round up some fairly serious hardware to run 
large tests on.  I guess I'm running on the assumption that testing will 
involve random number generated test cases that are parameterized for how 
long (or how many) cases to run. But maybe someone knows a better way.)

Anyhow, here to two major opportunities to get your name in lights, or at 
least added to the Boost people page.  Think about volunteering to write 
example applications or a test framework!  Presumably both would become 
part of the permanent library.

--Beman