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