Date: 2007-08-30 13:00:02
I played with it a while, and traced it down to behavior of
interprocess_condition, I think. I hope I have the correct idea for barrier...
Expected behavior: N threads wait on the barrier, at which point, the barrier lets
all N threads continue (exiting wait()). One of these threads is indicated as the
"leader", by a unique-in-n return value of True. Eh?
Actual Behavior: For an interprocess_barrier(n), when the nth thread waits on the
barrier, only one thread is successfully released as the "leader." The others are
all blocked before exiting interprocess_barrier::wait(), and (by some mutex
condition I don't completely understand) they block the leader from re-entering.
So I don't have a solution, but I know where the problem is. If you look at all the
threads running during the deadlock, the "leader" is trying to get past the
m_entry_lock code at the top of interprocess_condition::do_timed_wait(), and
the rest are locked on the external_lock.lock() call at the very bottom of the
same function. The likelihood I get to this before the weekend is zero, so if
someone wants to look at the implementation of interprocess_condition, that
would be the place to go. Else I'll try a fix on Saturday.
-- Tack ---- Original message ---- >Date: Thu, 30 Aug 2007 11:42:26 -0400 >From: "Jaime Rios" <xdev74_at_[hidden]> >Subject: Re: [boost] [Interprocess] barrier_test hanging on Apple PowerPC >To: boost_at_[hidden] > >Has this issue been resolved? I don't see any activity on this issue and the >threading issue is appearing on PowerPC projects. > > >-- >-Jaime >http://www.jaimerios.com >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/ boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk