Re: [boost] Possible issue with Boost.Atomic (and consequently Boost.Thread)

Subject: Re: [boost] Possible issue with Boost.Atomic (and consequently Boost.Thread)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-04 09:51:24

On Wed, Dec 4, 2013 at 6:27 PM, Peter Dimov <lists_at_[hidden]> wrote:
> In
>
> https://svn.boost.org/trac/boost/ticket/9466
>
> it is reported that using Boost.Thread on AIX without defining
> BOOST_THREAD_DONT_USE_ATOMIC causes an assertion failure in
> boost/smart_ptr/detail/lwm_pthreads.hpp (pthread_mutex_lock failing with
> EINVAL.)
>
> As I explain in the ticket, what I think happens is that Boost.Atomic falls
> back to its generic lock pool implementation, which uses a static array of
> 41 boost::lightweight_mutex objects.
>
> However, since lightweight_mutex has a constructor calling
> pthread_mutex_init and a destructor calling pthread_mutex_destroy, using
> call_once, directly or indirectly, outside main can lead to accessing a
> mutex object before it's constructed or after it's destroyed, depending on
> static initialization order.
>
> If I'm correct in this assumption, then lockpool.hpp/.cpp need to be fixed
> to either use boost/smart_ptr/detail/spinlock_pool.hpp*, or use statically
> initialized pthread mutexes directly.
>
> *) Which is basically what it was designed for, see the comment:
>
> //  spinlock_pool<0> is reserved for atomic<>, when/if it arrives

Yes, I'll have to replace lightweight_mutex with pthread_mutex_t with
static initialization. I think in terms of dependency management this
would be better than depending on Boost.SmartPtr. This will only work
on platforms with PTHREAD_MUTEX_INITIALIZER, but I don't know any
platform without it. Windows is handled with intrinsics, so it should
not be a problem.

Could you assign the ticket to Boost.Atomic and me? I'll try to take a
look at the weekend.

PS: Are we done with the transition to git?