Re: Boost.Threads: volatile methods of mutex class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-30 10:08:07

--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- 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):

As your "work in progress" matures I'd love to hear about your 
experiences.

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

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

I would think that generating the name would be simple and a "clean" 
solution... but not if there's a need to use the name after the 
thread is created.  Hopefully in the future we'll be adding an 
interface to allow for creation of threads using platform specific 
parameters which will allow you to create these threads with this 
name using a "standard" interface.  I'm just not sure how I'll 
implement this yet.
 
> > 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).

I'd like to know about any specific changes you have to make so that 
I can consider the changes and how it might be possible to do it 
portably.

Now that you've brought the volatile stuff to my attention I'll look 
into how to fix things here.  Thanks for the report.
 
> > 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.

Hopefully.

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

Your experiences are still valuable, both for the people on the 
committee in evaluating things, and for me in designing the most 
flexible interface I can.
 
Thanks,
Bill Kempf