Topic: N2659 : Thread Local Storage Q's


Author: "R. Douglas" <rwdougla@gmail.com>
Date: Thu, 17 Dec 2009 11:59:43 CST
Raw View
I began looking into, what I understand, is the final proposal of
Thread-Local Storage and have a few questions, that I hope someone may
be able to clarify. I was surprised to find almost no discussion of
either N2659 or it's predecessor, N2545 on here or through Google.

 From N3000, 3.7.2.1:
"There is a distinct object or reference per thread, and use of the
declared name refers to the object or reference associated with the
current thread."

I see the great benefit for function scope statics, but is there any
way to declare an object of namespace scope as thread_local, and only
have it included by threads created for a particular purpose? I assume
the answer is no, since I have not found any such proposal or
discussion. If that is the case, then I am at a bit of a loss as to
what sort of data in the namespace scope would be useful for *every*
thread in an application, regardless of what the purpose of the thread
is. (except, perhaps, counting how many times that particular thread
accessed a global logging utility, but I am inclined to view that as
being of truly limited utility)

The ease of use of such a tool seems to make it very tempting for
programmers moving code forward from single threaded to multi threaded
architectures, to make numerous namespace scope variables
"thread_local." This could very well result in "correct code," so it
would seem harmless to the hapless user of the new keyword. The
biggest "gotcha" would then seem to occur, when you link against a
library that was written this way, and now every thread your code
creates, has a storage location for *every* namespace scope variable
that was declared thread_local in that other library.

Should it just become a new maxim for programmers new to C++0x, to be
even more wary of namespace scope thread locals, than they are told to
be for single-threaded programming namespace scope variables?

Best Regards,
-Rob

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]