Re: [boost] Re: boost.threads

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-09 12:14:21

From: <williamkempf_at_[hidden]>
> > 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.