From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-01-29 16:45:42
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:24 PM 1/29/2002, davlet_panech wrote:
> > ... I recently ported (portions of)
> >Boost.Threads to a platform (pSOS) ...
> Please tell us a bit more of your experiences with Boost.Threads
> What problems? What successes?
There isn't much to tell yet, as it is still work in progress; most
of the problems we are having are due to the non-conformant compiler
we are forced to use (DIAB 4.3):
- The biggest problem with DIAB 4.3 is it's lack of support for
namespaces, which makes many of the Boost libraries unusable. In
contrast, we did "port" most of the pieces of (ANSI C++) standard
library successfully as the current standard library doesn't use
namespaces as extensively as Boost does. I would really prefer Boost
libraries not to use nested namespaces, but the only reason I am
saying this is because we are stuck with an old compiler.
- pSOS supports semaphores, but neither mutexes nor condition
variables (both of these can be implemented in terms of semaphores,
so that's OK)
- pSOS doesn't have a concept of threads per se, it has "tasks": all
tasks running on the same processor share all resources (these are
analogous to threads), "remote" tasks (executing on a different
processor) are also possible, these are analogous to processes. I
guess Boost.Threads package would have to be limited to reprsent
local tasks only.
- Each pSOS thread ("task") has a 4-character name associated with
it; it *must* be specified at creation time (these names are useful
for accessing remote tasks). To support this Boost.Threads would have
to either generate those names somehow, or allow the user to specify
> Have extensively is your port being used?
Boost.Threads is the only library we are using at this time (our
version has a slightly different interface -- for the reasons
mentioned above). We are very pleased with it's design; I guess the
only issue is the question on usage of `volatile' modifiers (see my
> What are your feelings about Boost.Threads in relation to C++
I am all for it! I have used other C++ thread packages in the past,
and I really like the direction this one has taken, especially with
thread cancellation, which is (hopefully) coming up soon.
> One of the key questions the committee will ask is "how well does
> design work on various operating systems?"
> So even when a port of Boost.Threads is proprietary, and can't
> of the Boost distribution, it is still helpful to hear about the
I'm not convinced our port will be very useful (if and when it is
completed), mainly because we have to change the interface to work
around compiler defficiences; besides we are not porting the whole
library, only portions of it that are most useful to us.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk