Boost logo

Boost :

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.

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.

---- 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.
>Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at