Re: [Boost-bugs] [Boost C++ Libraries] #9466: shared_ptr fails with EINVAL on AIX 7.1 when compiled with atomic

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9466: shared_ptr fails with EINVAL on AIX 7.1 when compiled with atomic
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-12-04 14:17:40

#9466: shared_ptr fails with EINVAL on AIX 7.1 when compiled with atomic
-------------------------------+-----------------------
  Reporter:  pat <pat@…>       |      Owner:  pdimov
      Type:  Bugs              |     Status:  new
 Milestone:  To Be Determined  |  Component:  smart_ptr
   Version:  Boost 1.55.0      |   Severity:  Problem
Resolution:                    |   Keywords:
-------------------------------+-----------------------

Comment (by pdimov):

 As far as I can see, BOOST_THREAD_DONT_USE_ATOMIC only affects
 boost::call_once, forcing it to not use Boost.Atomic. So something must be
 using call_once. It's possible that some Boost library is using it
 internally.

 What I think happens is the following. Boost.Atomic, under AIX, falls back
 to its generic lock pool implementation in
 boost/atomic/detail/lockpool.hpp and libs/atomic/src/lockpool.cpp. This
 uses boost::lightweight_mutex, and consequently lwm_pthreads.hpp.

 The mutex pool (a static array of 41 lightweight_mutex objects) is defined
 in libs/atomic/src/lockpool.cpp. However, since lightweight_mutex has a
 constructor calling pthread_mutex_init and a destructor calling
 pthread_mutex_destroy, it is possible for call_once to end up using this
 mutex pool before it's constructed or after it's destroyed, depending on
 static initialization order.

 If I'm correct in this assumption, then your workaround of defining
 BOOST_THREAD_DONT_USE_ATOMIC is the right one for now. We'll see how we
 can fix the problem on our side.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9466#comment:7>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.