Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : Gianni Mariani
Date : Tue Feb 22 2005 05:58 am

Alexander Terekhov wrote:
> Gianni Mariani wrote:
> [...]
> 
>>If you require threads to be able to share thread specific objects,
>>they're, by defintion, no longer thread specific !  Kind of an oxymoron.
> 
> 
> __thread lvalues designate different objects depending on thread. The
> mappings are "thread specific", but objects are not (apart from having
> "thread-specific" lifetimes). They are not "thread-private". Just like
> objects with automatic storage duration are not "thread-private". Got
> it?

I don't think you got it.

The merits of thread specific mappings vs "thread-private" objects are 
few if any.  As a developer, I can easily implement thread specific 
mappings using "thread-private" objects, but not visa versa.  There are 
definite merits to having objects accessible by only a single thread. 
What practical use is there in supporting only "thread specific" object 
mappings ?

.