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. Deadlock. 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@gmail.com> Subject: Re: [boost] [Interprocess] barrier_test hanging on Apple PowerPC To: boost@lists.boost.org

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