[cpp-threads] Update on N2889/N2880/N2901

[Peter Dimov]

Your thread_local analysis is a bit off (politely speaking).

- Thread locals are used in code that does not have control over the threads 
from which it's called. You can't just replace a thread_local with a 
stack-local in the thread because you have no control over the stack of the 
thread. If you could, there'd obviously be no need for thread locals. But 
there is, no matter how much you try to theorize them out of existence.

- Thread locals need destructors in C and C++ (and not in Java) because 
there's no GC. You can't just allocate per-thread state and keep it in a raw 
pointer, because you'll leak it on every thread completion. You need (at 
minimum) (the equivalent of) thread_local auto_ptr or shared_ptr.

- Thread locals are not of limited value when there is thread reuse; on the 
contrary, they are very useful in this case. Thread locals are often used as 
a performance optimization to cache per-thread data and avoid 
synchronization. Without thread reuse, every task will hit the global state, 
incurring synchronization penalties. With thread reuse, tasks can be served 
from the local, per-thread cache.

The straightforward and well-known example that plainly illustrates the 
above three points is malloc/free with thread-local free lists.

Regarding lifetime issues with thread locals: POSIX thread locals are 
basically Phoenix singletons. Under a typical use pattern, they would be 
reconstructed on first use and this will happen even after destruction (no 
UB). If this occurs, they will be destroyed again. There is an an 
implementation-defined number of destruction cycles, after which the 
implementation gives up. (Arguably, the C-based POSIX API is better at 
static construction/destruction in the MT case than C++ is in the 
single-threaded case.)

--
Peter Dimov
http://www.pdplayer.com

----- Original Message ----- 
From: "Herb Sutter" <hsutter at microsoft.com>
To: "C++ threads standardisation" <cpp-threads at decadentplace.org.uk>
Sent: Sunday, June 21, 2009 18:06
Subject: [cpp-threads] Update on N2889/N2880/N2901


Update: Lawrence and I spoke on the phone a couple of times on Friday, and 
as of this moment we still have two async proposals, but we will work 
further this afternoon to see if we can yet converge our proposals into a 
unified async proposal. (Thanks again for your continued efforts, Lawrence!)

However, our chats on Friday have already illuminated a clearer(?) 
understanding of the N2880 issues that prompted us to agree that I write a 
paper that tries to more clearly lay out the fundamental issues involved.

Here is a draft of that additional paper, primarily for Lawrence's review 
but also for anyone else who's working on Sunday. Thanks,

Herb




--------------------------------------------------------------------------------


> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>