Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : David Schwartz Date : Wed Feb 16 2005 06:15 am "Alexander Terekhov" wrote in message news:42134D96.301D276E@web.de... >> > Objects with __thread storage duration are no more "thread-private" >> > than objects with automatic storage duration (auto stuff). >> >> What standard requires this? > > The International Common Sense Std. Unwritten. Obviosly we don't agree on what constitutes common sense, so just claiming your view is common sense won't help you. >> > IOW, they >> > are NOT thread-private. Doing it otherwise is utterly brain-dead. >> >> You have said this, but not explained why. > > Threads != processes (not even "enclaves" in IBM LE terms). We are talking about a particular technical definition of "threads", not the generic one. Specifically, the standard defines a thread as "a flow of control through a program". It does not require any of the specific implementation details that normally accompany the term. It specifically leaves that to the threading standard. >> It should be obvious that for the vast majority of cases, what you >> are >> claiming is required is not required. > > As-if rule, you know. I don't follow your reference here. >> Further, in most cases, it results >> in >> dramatically reduced performance. > > Really? Can you back this claim up with facts? Umm, it's totally obvious. For your method, every reference to thread-specific data (assuming you don't cache the address) requires figuring out which thread you are to calculate the address. For my method, accessing thread-local data is no different from accessing global data. The cost of a context switch is, presumably, higher with my method (because some TLB entries have to be flushed), but if context switches are so frequent that their cost matters, you've already lost due to cache thrashing. >> Notice no mention of share memory in the definition of threads. >> Notice >> no discussion of the semantics of taking the address of a thread-local >> variable. > So what? So the standard doesn't include all these other things for what I think are good reasons. You should not rely upon what's not in the standard. If you do, you will either break on or constrain future implementations, and either way that's bad. > It doesn't say that taking the address is undefined or that > threads can't access objects with thread storage duration "owned" by > other threads. Right. > The only sensible conclusion is that "normal rules" of > the C{/POSIX} object model are perfectly applicable and portable > programs can rely on them for objects with thread storage duration as > well. The problem is, which is normal? If you pass the address, is it normal for threads to access each other's thread local variables? Or is it normal for each thread to access its own? Reasonable people can disagree, and it comes down to, fundmentally, what does "thread local" mean? The C++ standard, as far as I can tell, even envisions threading implementations that are not at all POSIX-like. Such as ones where the stack is literally switched on a thread switch and only one thread can run at a time. On such implementations, it's quite natural to swap the thread-local data with the stack. Such implementation were common in the past, and I can see no evidence whatsoever that the "__thread" definition meant to rule them out. DS .