RE: [boost] Re: boost.threads

From: Darryl Green (green_at_[hidden])
Date: 2001-08-08 00:08:54

> -----Original Message-----
> From: John Max Skaller [mailto:skaller_at_[hidden]]
> Sent: Wednesday, 8 August 2001 7:09 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: boost.threads
> 
> 
> Darryl Green wrote:
> 
> > I do realise C++ will be perfectly happy for you to
> > do this. 
> 
> 	no: it will be happy if an only if the abstract
> machine is extended to support interthread sharing
> of stack data. At present, C++ is very unhappy 
> immediately you create a thread: all bets are off.

Oops - I forgot to include a glossary to define happy
(and C++) :-) By happy C++ I was simply agreeing with
Benman that "commonplace code" on at least the plaforms
Benman appears interested in supporting will work.
I don't mean it is guaranteed to work by the language
standard or anything else.

> > I had assumed that
> > the issue was whether any guarantees could or needed to
> > be made about the consequences of doing this.
> 
> 	That's a different (kind of) issue, the kind
> Bill is trying to deal with by providing a library
> that at least _helps_ do thread safe programming
> a bit more easily (meaning both safely and portably).
> 
> 	Generally, the abstract machine is just there
> so you can say things .. not to provide any safety.
> Occasionally, it can be characterized in such a way that
> some optimisations are possible. 
> 
...
> What if you exploit the well know 'this' loophole?

That requires what one might call malicious intent,
and in particular localised (in the constructor of
the const object in this case) meddling to do it.
Benman suggests that another thread should expect
evil consequences if it tries to access the stack
of a terminated thread and that this is similar 
(identical) to what will happen in a single
threaded environment if an attempt is made to
access the stack of a function that has returned.
This is true, but it is relatively easy to avoid
in the single threaded case. It is very hard to
avoid unknowingly making a similar error in a
multi-threaded program. Hence I don't share
automatic storage and I'm unlikely to start now.
In any case I think I have finally got the point
that was originally being discussed (sorry for
the diversion...).
So far as your concerns re the optimisatation
of stack storage go, I do think there will be
an awful lot of more exotic embedded (and other)
systems which will place restrictions on where
shared data can live. Perhaps it is a mistake
to try to make them fit within the multithreaded
model. It may be necessary to treat these as various
forms of shared memory system, which is probably
a bit beyond the scope of the Boost.Threads
library and/or the C++ language standard?

Darryl Green.