TLS is most useful when doing "thread specific singletons". A neat hack,
but the wisdom of any singleton pattern always has to be queried...
Agree with Alan.
On 15/03/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
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.
>
>
