True, but in the case where you are writing the API you could always leave
room to pass the needed values down the stack. Its a sort of 'magicians hat'
trick, where per thread variables are managed behind the scenes. Doesn't let
you do anything you could not otherwise do.
In the example I gave, there was no room in the API (because I had no
control over it), but I was able to pass per-thread values through it and
out the other side by using thread locals. Using thread locals made it
possible to do something I could not otherwise do, which is genuinely
usefull.
Rupert
On 24/03/07, John O'Hara <[EMAIL PROTECTED]> wrote:
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.
> >
> >
>
