Date: 2001-08-07 08:43:50
--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > 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
> > execution environment include, but are not limited to, the
> > · Static storage duration (static, extern) objects [3.7.1].
> > · Dynamic storage duration (heap) memory [3.7.3]. Thus each
> > allocation will return a unique addresses, regardless of the
> > 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
> > function of the same program, not a totally different program.
> > Each thread has its own:
> > · Registers and current execution sequence (program counter)
> > · 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
> > objects, I don't think it would allow a conforming thread
> 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.
However, the theoretical extension to the language should do this one
right, and not follow the lead of __declspec(thread) here. There are
numerous ways in which this MS concept is broken, most in regard to
how DLLs behave. Though the standard doesn't address DLLs
specifically, I'd hope the wording was chosen carefully enough to
remove these errors.
> thread local/specific dynamic storage duration memory/objects - that
> is basically what pthread_get/setspecific (or javas ThreadLocal)
Not much need for this when you've got the static variety... provided
you've also got some sort of atexit() callback type of functionality
for threads. You'd simply declare a static pointer and register an
exit routine to cleanup any memory referenced by this pointer, giving
you the exact same functionality as what's provided for with
pthread_get/setspecific, but with more "standard" syntax.
So, what's really needed are two different keywords for two new types
of declarations: synch and thread_local. Types declared as "synch"
are gauranteed to be initialized only once regardless of attempts by
multiple threads to do so. Types declared as thread_local are
created/initialized at first use with seperate instances for each
thread that does so.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk