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