From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-07 07:27:21
> I've reformulated the description:
> Unless otherwise specified, each thread shares all aspects of its
> environment with other threads in the program. Shared aspects of the
> execution environment include, but are not limited to, the following:
> · Static storage duration (static, extern) objects [3.7.1].
> · Dynamic storage duration (heap) memory [3.7.3]. Thus each memory
> allocation will return a unique addresses, regardless of the thread
> the allocation request.
> · Automatic storage duration (stack) objects [3.7.2] accessed via
> or reference from another thread.
> · Resources provided by the operating system. For example, files.
> · The program itself. In other words, each thread is executing some
> function of the same program, not a totally different program.
> Each thread has its own:
> · Registers and current execution sequence (program counter) [1.9/5].
> · Automatic storage duration (stack) objects [3.7.2].
> >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.
and a lot of existing C/C++ code would become broken if auto
storage would become non-GLOBAL/thread non-shareable. however,
IMHO it would be really great if the new thread-aware C++ would
introduce two new "standard" storage types/durations:
thread local/specific static storage duration memory/objects - that
is basically what MS VC __declspec(thread) does.
thread local/specific dynamic storage duration memory/objects - that
is basically what pthread_get/setspecific (or javas ThreadLocal) does.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk