Re: [boost] [Interprocess] barrier_test hanging on Apple PowerPC

From: atack2_at_[hidden]
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. 
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_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