Thread locals are more usefull when calling third party code. For example
when a pre-existing API prevents you passing references down on the stack
explicitly. I used it in the junit-framework, for example, because I need to
keep context against threads as I called tests that then call back into the
framework, but existing junit APIs that I wrapped, didn't provide any room
for these to be passed in as arguments.
Alan, I agree. If its your own code, just hand the references you need down
the call stack. Even in Java, you have to be very carefull about cleaning
these things up.
Rupert
On 3/15/07, Alan Conway <[EMAIL PROTECTED]> wrote:
Andrew Stitcher wrote:
> I've just been doing a little thinking and reading about improving the
> scalability of the C++ broker: One of the things that occurred to me is
> that some things may be improved by using thread local variables to
> avoid globally shared state and hence locking. In particular in places
> where things are guaranteed to happen on the same thread - for example
> the processing of an incoming frame.
>
> Looking into this it appears that gcc has an extension that allows you
> to declare thread local variables ("__thread"). Previously I've used the
> equivalent Visual Studio magic (something like __declspec(thread)), so I
> imagine it's a widespread extension.
>
> Does anyone have experience of using thread local vars with these
> extensions? Are there any opinions about using a non-standard feature
> like this in a core place in the C++ broker?
>
Haven't used the gcc extensions but I've used portable TLS templates
(old job, proprietary code) Getting shutdown/delete right is hours of
fun. As long as we wrap the use of __thread in a class we can always
replace it with a native TLS impl if/when we need to support another
compiler so I don't see anything disastrous in using gcc extensions.
E.g. boosts atomic_count takes this tack - using gcc extensions if built
with gcc and using platform atomics or fall-back to mutex.
TLS is bad for the same reasons global variables are bad and then some.
In general I would much prefer to keep thread context on the thread's
stack. TLS does have its uses but in my experience they're mostly about
working around an existing broken design that can't be changed for some
reason. I would consider it only if I'm convinced that it's the only way
to solve some problem, but I would look hard for alternatives first.
Major caveat: TLS is a very rare resource on some platforms - as few 512
variables on some platforms. So it's very important to use a small
fixed number of slots, preferably 1. Under *no circumstances* should
non-singleton objects have TLS members.
Cheers,
Alan.
