On Nov 24, 2013 10:14 AM, "beet" <r.berlich@gemfony.eu> wrote:
>
> Am 24.11.13 19:09, schrieb Klaim - Joël Lamotte:
> > My understanding is that the point of thread-local objects is to allow
> > avoiding any kind of locking
> > when you know that an object have to be called exclusively from a
> > specific thread and
> > that each thread using that object will have it's own copy.
> >
> > So no there is no locking. However it is not clear if you are asking
> > about Boost.Thread thread-local
> > smart pointer utility, or C++11 thread_local language feature?
>
>
> Hi,
>
> the question actually referred to Boost.Thread thread-local smart
> pointer utility. I cannot use C++11, and Boost is (as is so often the
> case) the only way to get portable, advanced functionality with older
> C++ standards.
>
> Best Regards,
> Beet
>

If you are designing this more-or-less from scratch, I would avoid using a thread local variable for this.  It is approximately the same kind of bandaid as a global variable.

My advice would be to pass around some kind of per-thread context that includes your rng. 

However, if that doesn't work for some legacy reason, and these portable tls mechanisms don't work, you can manage your own tls with compiler specific wrappers with significant performance improvement (at least I saw a big improvement a few years ago... it is possible that the portable mechanisms have improved).

  Brian