I altered the code from this: else{ //Notification occurred, we will lock the checking interprocess_mutex so that //if a notify_one notification occurs, only one thread can exit //--------------------------------------------------------------- InternalLock lock; if(tout_enabled){ InternalLock dummy(m_check_mut, abs_time); lock = boost::interprocess::move(dummy); } else{ InternalLock dummy(m_check_mut); lock = boost::interprocess::move(dummy); } if(!lock){ timed_out = true; unlock_enter_mut = true; break; } //--------------------------------------------------------------- boost::uint32_t result = detail::atomic_cas32 (const_castboost::uint32_t*(&m_command), SLEEP, NOTIFY_ONE); to this: else{ boost::uint32_t result = detail::atomic_cas32 (const_castboost::uint32_t*(&m_command), SLEEP, NOTIFY_ONE); and I have had no further problems in my tests. -Zach -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga Sent: Wednesday, September 16, 2009 11:33 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Interprocess] deadlocking race conditionin emulation interprocess_condition.hpp Young, Zachariah L escribió:
Actually, why lock the m_check_mut at all?
Why not delete that whole thing and remove the m_check_mut from the class entirely, as it apparently exists only to synchronize the get and set of m_command on line 177 (before any edits), which is an atomic compare-and-set (ie, doesn't need synchronization)?
-Zach
I reach the same conclusion just a minute ago. Could you test your code removing this mutex? Best, Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users