Hi there, I have a number of threads and, within the context of each thread, a large number of objects may be active. I would now like to provide all objects accessed by a thread with a common random number generator. i.e., there would be as many random number generators as there are threads, and all objects active inside of a given thread would access the same generator, but objects in different threads use different generators. The obvious approach would be to store the generator in thread-local storage. I am concerned, however, about the performance implications. In particular, does access to thread-local storage implicitly involve locking of sorts? If so, the (very) frequent access to the random number generator would effectively serialize my application. Thanks and Best Regards, Beet
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?
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
On Nov 24, 2013 10:14 AM, "beet"
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
participants (3)
-
beet -
Brian Budge -
Klaim - Joël Lamotte