Re: [Boost-users] [system] local static and threading in C++03

Le 27/12/12 21:32, Felipe Magno de Almeida a écrit :

On Thu, Dec 27, 2012 at 5:42 PM, Vicente Botet wrote:

...

Felipe Magno de Almeida wrote

...

On Thu, Dec 27, 2012 at 9:30 AM, Vicente Botet < vicente.botet@ [snip]

...

...

...

Form a theoretical point of view yes. But in practice, which observable problems could induce the double construction? Could you answer this question? I don't think I can. It is a race condition. What can happen? Anything I guess, it would depend on the implementation. I do feel very uneasy about concurrency bugs. They do bite.

...

...

...

I would expect only one destruction, don`t you? No, I wouldn't. If it is constructed twice, I would expect atexit to be called twice as well. So double destruction. I don`t know. Anyway, which observable problems could induce this double destruction? I think double-free of allocated memory is quite possible, but I think anything is possible depending on implementation details. I rather not rely on implementation details. I don't see any allocation there. Boost has a lot of code that depends on compiler implementation details. Also, I was expecting race conditions to be taken more seriously than to wait for bad behavior to appear. It is, afterall, a correctness issue. You are right. the issue should be taken in account.

Does the following schema extracted from Boost.Units solve the issue or it works only for POD types? namespace detail { template<bool> struct xalloc_key_holder { static int value; static bool initialized; }; template<bool b> int xalloc_key_holder<b>::value = 0; template<bool b> bool xalloc_key_holder<b>::initialized = 0; struct xalloc_key_initializer_t { xalloc_key_initializer_t() { if (!xalloc_key_holder<true>::initialized) { xalloc_key_holder<true>::value = std::ios_base::xalloc(); xalloc_key_holder<true>::initialized = true; } } }; namespace /**/ { xalloc_key_initializer_t xalloc_key_initializer; } // namespace } // namespace detail /// returns flags controlling output. inline long get_flags(std::ios_base& ios, long mask) { return(ios.iword(detail::xalloc_key_holder<true>::value) & mask); }

[snip]

...

...

...

This approach would make both libraries interdependent. I don't understand what you mean. Boost.System will depend on Boost.Thread and Boost.Thread already depends on Boost.System. I see. I rather they be interdependent than to have race conditions. And I don't think call_once requires boost.system. So at least cyclic includes could be avoided.

Yes, but this will mean to have two Boost.Thread libraries boost_thread (with call_once) and boost_futures (which depend on Boost.System). I'm not against this but this will mean a new breaking change. Best, Vicente