Possible issue with Boost.Atomic (and consequently Boost.Thread)
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
On Wed, Dec 4, 2013 at 6:27 PM, Peter Dimov <lists@pdimov.com> 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?
Andrey Semashev wrote:
Could you assign the ticket to Boost.Atomic and me? I'll try to take a look at the weekend.
OK, done. I'm not 100% sure that this is the cause of the problem in the ticket though. It will need to be verified once you have a substitute lockpool.
On Wednesday 04 December 2013 17:41:58 Peter Dimov wrote:
Andrey Semashev wrote:
Could you assign the ticket to Boost.Atomic and me? I'll try to take a look at the weekend.
OK, done. I'm not 100% sure that this is the cause of the problem in the ticket though. It will need to be verified once you have a substitute lockpool.
Well, the fact that the lock pool is initialized dynamically is obvious, so it's worth fixing anyway. This is more so considering that atomic<> can be used by call_once. But I didn't inspect shared_ptr code to figure out how it is connected to call_once, as the ticket seems to imply. If you want to test shared_ptr (especially, if you have access to AIX) when the lock pool is fixed I could return the ticket to you instead of closing it.
Andrey Semashev wrote:
If you want to test shared_ptr (especially, if you have access to AIX) when the lock pool is fixed I could return the ticket to you instead of closing it.
I'm fairly sure that the ticket has nothing to do with shared_ptr and I have no access to AIX. What I meant was that once you're ready with a replacement lockpool.hpp/.cpp, you might ask the ticket submitter to check whether using these and rebuilding Boost.Atomic (and Boost.Thread without defining BOOST_THREAD_DONT_USE_ATOMIC) takes care of the problem.
participants (2)
-
Andrey Semashev -
Peter Dimov