Re: boost.threads

From: williamkempf_at_[hidden]
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
> execution
> > 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
> making
> > the allocation request.
> >
> > ·  Automatic storage duration (stack) objects [3.7.2] accessed via
> pointer
> > 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.

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) 
does.

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.

Bill Kempf