Re: Boost.Threads: where do we go from here?

From: williamkempf_at_[hidden]
Date: 2001-03-22 18:22:24

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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.

I concur with Beman's reasonings here totally.  However, there are a 
few minor things preventing us from taking this next step.  So, I 
propose tackling these small problems first, and I can't do them on 
my own.

We need to get Boost.Threads to compile with all the current 
compilers targeted by Boost that run on Windows or that run on 
platforms with pthread support.  This means modifications to 
config.hpp and some sort of build system for each targeted compiler.  
Since the code currently doesn't reside on a CVS repository I guess 
it means that such modifications need to be sent to me and I'll merge 
them into the uploaded archive which can then be tested.  For config 
changes it's best to send me the information about what section of 
config.hpp is targeted along with the needed macro definitions.  I'm 
not sure that a diff file will work here since I'll be servicing 
multiple patches, but then I've not used diff much in the past so if 
someone with more knowledge here wants to explain how this could be 
done (in private e-mail preferrably) then we can go that route.  The 
macros needed should be easily figured out by reading the config.html 
file in the doc directory.  As for build routines, they should be 
built to run against the current directory structure found in the 
archive and should exist and be run from the build directory.

Another issue with creating example applications is the lack of 
thread creation and manipulation interfaces.  I think it may be valid 
to create platform specific applications in some cases (i.e. use the 
native thread manipulation routines).  In others it may work to take 
the same approach that I did in my examples, i.e. use the soon to be 
removed routines in boost::detail in thread.hpp.  If you take this 
route and find the adhoc implementations don't work for your examples 
you'll have to send me modifications to include in the archive.

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

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

These are the classic MT models.  They aren't really problems, per 
se, but approaches to solving problems using MT.  It shouldn't be too 
hard to find problems/examples using these models, though, which is a 
good starting strategy.

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

Along these lines, if bugs/issues are found while implementing the 
example programs it would be nice if they could be captured in simple 
unit tests that can be added to test_thread.cpp.  This test framework 
isn't enough to actually test the whole library, but it's needed to 
test implementations for compliance when running regression testing 
before Boost releases.

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

You're name will also be added to acknowledgement pages if you supply 
the information needed to build Boost.Threads for any platforms.

Bill Kempf