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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-03-22 20:38:42

Bill,

I'll help with some of this stuff, but not for ten days or so until I get 
back from the ACCU conference in England.

It will be way easier if you have write CVS access.  So you might want to 
work on getting WinCvs (or whatever client you prefer) installed, and get 
going on learning how it all works.  Get (or reactivate) your SourceForge 
account, practice read-only activities (like updates for a few days as 
other developers make changes to their libraries, branch checkouts, etc.), 
and in general make as many mistakes as possible before you actually are 
writing to the live CVS.

I found CVS very frustrating to get going, but then a tremendous help once 
the initial hurtles were past.  Some of the things I'm willing to help a 
bit with like documentation, I would only consider doing via CVS.  Just too 
much trouble to email you about spelling changes, for example.  And with 
CVS, you can always back out changes others make if you don't like 
them.  (Normally you would be the only one to make substantial changes, but 
with stuff like platform workarounds it is just wonderful to have someone 
else contribute a fix.)

I'm CC'ing Dave and Jens so they know what you are doing and can perhaps 
help if you have CVS questions.

--Beman

 >--- 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
 >
 >
 >To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
 >
 >
 >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/