Re: [boost] Re: boost.threads

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-07 16:37:31

At 01:42 PM 8/7/2001, John Max Skaller wrote:

 >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.
 >
 >	Sounds like a question for embedded programming people.

Yes.  But for Boost.Threads, we want to stick closely to the thread 
execution model we think is already supported by virtually all current UNIX 
and Windows compilers.  We aren't trying to break new ground here.  So the 
memory rules for what functions in different threads can access have to 
stay as close as possible to the current rules for what separate functions 
in the same thread can access.

--Beman