Boost logo

Boost :

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
> unique difficulties.
> See the Threads Roadmap I presented last October in Toronto:
> 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
> process. Now it is time to look at some of the others:
> * Example applications. We need these to make sure the design is
> in practical problems, to compare to other solutions, and to try to
> 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
> the developer actually using software to identify issues. Plus
> spreads the workload.

> It also seems to me that it would be useful if the examples were
> known, and had implementations using other threading packages for
> comparison. David Butenhof's "Programming with POSIX Threads"
> (chapter 4) three "primary models for threaded programming" and
> 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
> 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
> understood how to test this sort of system. Fiendish is the word
> 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
> involve random number generated test cases that are parameterized
for how
> long (or how many) cases to run. But maybe someone knows a better

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
> example applications or a test framework! Presumably both would
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at