[function] Function scope static not thread safe
The following code in function_template.hpp has me concerned: template<typename Functor> void assign_to(Functor f) { static vtable_type stored_vtable(f); if (stored_vtable.assign_to(f, functor)) vtable = &stored_vtable; else vtable = 0; } The function scope statics are not thread-safe as far as I know and this is potentially a show stopper for us (we're in the process of upgrading from 1.33.1 to 1.34+. Same usage in boost.serialization caused our application (very heavy threaded) to crash. Is there any plan to fix this? Or I'm wrong and this is not a problem. Regards, Sean
On Sep 13, 2007, at 12:24 AM, Sean Huang wrote:
The following code in function_template.hpp has me concerned:
template<typename Functor> void assign_to(Functor f) { static vtable_type stored_vtable(f); if (stored_vtable.assign_to(f, functor)) vtable = &stored_vtable; else vtable = 0; }
The function scope statics are not thread-safe as far as I know and this is potentially a show stopper for us (we're in the process of upgrading from 1.33.1 to 1.34+. Same usage in boost.serialization caused our application (very heavy threaded) to crash.
The good news is that even though this requires dynamic initialization of the static, the initialization itself is merely copying two function pointers. Running the initialization twice is no problem: it will just provide the same pointer values. The bad news is that, if the initialization gets skipped, you will get a crash.
Is there any plan to fix this? Or I'm wrong and this is not a problem.
Well, *now* there's a plan to fix it :) Thanks for reporting this. It's ticket #1260, and the fix will be to turn that dynamic initialization of stored_vtable into static initialization, so that no code will actually need to be executed. - Doug
On 9/13/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
On Sep 13, 2007, at 12:24 AM, Sean Huang wrote:
{ static vtable_type stored_vtable(f);
Well, *now* there's a plan to fix it :)
Yes, I was just about to report the same thing. By the way, it also looks like boost.function is sensitive to packing/alignment (in particular, the small-object optimizations). So if I include function into 2 pieces of code and pass functions back and forth, they better have the same alignment! (And considering that boost.threads is typically compiled into a separate dll, and uses boost.function, it is not hard to run into the problem). I was working on a test and/or patch and/or etc to make sure I understand it correctly, but since function was brought up anyhow... Has this been seen yet? Do you think it is a boost issue, or a client issue? What do you think the best fix is? I think you could re-order the members (largest first), but that would still make arrays of functions suspect. Otherwise, should you be using the boost pre/post alignment headers? Tony
On Sep 14, 2007, at 3:24 PM, Gottlob Frege wrote:
By the way, it also looks like boost.function is sensitive to packing/alignment (in particular, the small-object optimizations).
So if I include function into 2 pieces of code and pass functions back and forth, they better have the same alignment!
Well, yes.
(And considering that boost.threads is typically compiled into a separate dll, and uses boost.function, it is not hard to run into the problem).
I was working on a test and/or patch and/or etc to make sure I understand it correctly, but since function was brought up anyhow...
Has this been seen yet? Do you think it is a boost issue, or a client issue? What do you think the best fix is? I think you could re-order the members (largest first), but that would still make arrays of functions suspect. Otherwise, should you be using the boost pre/post alignment headers?
I would typically consider this a client issue, but if a fix such as using Boost's pre/post alignment headers would make life easier for clients, I'll be happy to make the change. Test and patch would be greatly appreciated, of course :) - Doug
participants (3)
-
Doug Gregor -
Gottlob Frege -
Sean Huang