Re: Boost.Threads: volatile methods of mutex class

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) ...
> 
> Davlet,
> 
> Please tell us a bit more of your experiences with Boost.Threads 
and pSOS.
> 
> What problems?  What successes? 

Beman,

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

> 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 
previous post).

> What are your feelings about Boost.Threads in relation to C++ 
> standardization?
> 
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 
the 
> design work on various operating systems?"
> 
> So even when a port of Boost.Threads is proprietary, and can't 
become part 
> of the Boost distribution, it is still helpful to hear about the 
> experience.

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.

> 
> Thanks,
> 
> --Beman

Thank you,
D.P.