Use of thread local extensions

[Andrew Stitcher <as...@redhat.com>]

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?

Andrew

Re: Use of thread local extensions

[Rupert Smith <ru...@googlemail.com>]

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 <jo...@gmail.com> 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 <ru...@googlemail.com> 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 <ac...@redhat.com> 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.
> > >
> > >
> >
>

Re: Use of thread local extensions

[John O'Hara <jo...@gmail.com>]

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 <ru...@googlemail.com> 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 <ac...@redhat.com> 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.
> >
> >
>

Re: Use of thread local extensions

[Rupert Smith <ru...@googlemail.com>]

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 <ac...@redhat.com> 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.
>
>

Re: Use of thread local extensions

[Alan Conway <ac...@redhat.com>]

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.