Re: boost.threads

From: williamkempf_at_[hidden]
Date: 2001-08-09 12:38:44

--- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> From: <williamkempf_at_h...>
> > > Beman Dawes wrote:
> > >  
> > > > At 06:07 PM 8/5/2001, John Max Skaller wrote:
> > > > 
> > > >  >Question: does anyone share stack data between threads?
> > > >  >
> > > >  >Reason for asking:
> > > >  >
> > > >  >      1) Bemans model tries to ban this
> > > >  >      2) I objected
> > > >  >
> > > > 
> > > > My original formulation was confusing because it didn't 
clearly  distinguish
> > > > between stack data accessed directly by within its thread 
(not  shared) and
> > > > stack data access from another thread via pointer or 
reference (shared).
> > > 
> > > OK.
> > >  
> > > >  >but it occurs to me that on a multi-processor, the 
constraint
> > > >  >would allow CPU local memory to be used for the stack, which
> > > >  >could be a significant optimisation.
> > > > 
> > > > Since that would disallow inter-thread pointers or references 
to  stack
> > > > objects, I don't think it would allow a conforming thread  
implementation.
> > > 
> > > According to your (reformulated) rules.
> > > The question is: is the local (unsharable) stack a viable 
implementation,
> > > and if so, can we ban sharing stack data to allow that 
implementation
> > > without impacting programmers?
> > > 
> > > Shared memory is expensive, local memory is cheap.
> > > If threads can run with the stack on 'on board' memory which is 
on a
> > > separate
> > > high speed per CPU bus from main memory, they might run 
considerably
> > > faster: such memory can be cached without being flushed, since 
only
> > > one CPU can access it. 
> > 
> > I wouldn't expect the standard to allow this.  To do so safely 
you'd 
> > have to somehow distinguish between a pointer to this "local 
memory" 
> > and a normal pointer.  Most of us could not live with access 
> > violations caused by passing the wrong pointer type.
> > 
> > However, I see nothing wrong with platform specific extensions 
that 
> > made use of such local memory.
> 
> It seems a compiler for a "fast local stack" machine can simply note
> which local variables have their address used and not keep them on 
the
> fast stack.  Doesn't seem all that different from using registers 
for
> locals on a machine with register windows.

That's quite different than what's asked here, though.  Specifically 
note the following:

> > > The question is: is the local (unsharable) stack a viable 
implementation,
> > > and if so, can we ban sharing stack data to allow that 
implementation
> > > without impacting programmers?

A case by case evaluation by the compiler to optimize usage by 
placing certain data on this fast stack is quite different than 
blankly saying all thread stack data must be non-sharable so that 
they can be placed on such a stack.

Bill Kempf