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

Subject: Re: [Boost-users] [system] local static and threading in C++03
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-12-30 12:39:09

Le 27/12/12 21:32, Felipe Magno de Almeida a écrit :
> On Thu, Dec 27, 2012 at 5:42 PM, Vicente Botet <vicente.botet_at_[hidden]> wrote:
>> Felipe Magno de Almeida wrote
>>> On Thu, Dec 27, 2012 at 9:30 AM, Vicente Botet &lt;
>>> 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