id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1231	interprocess_condition (emulated) hangs after notify_all().	atack2@…	Ion Gaztañaga	"This bug has manifested itself in barrier_test execution on Mac OS (PPC) machines, where POSIX is not sufficiently implemented to support barriers at the kernel level. The [source:trunk/boost/interprocess/sync/emulation@39114 emulated synchronization primitives] are a basic implementation of the necessary primitives, based on spin-locks. Barriers are implemented by having [source:trunk/boost/interprocess/sync/emulation/interprocess_barrier.hpp@39114#L32 m_count] threads wait on a condition variable. When the [source:trunk/boost/interprocess/sync/emulation/interprocess_barrier.hpp@39114#L32 m_count'th] thread arrives, all threads are notified by a call to [source:trunk/boost/interprocess/sync/emulation/interprocess_condition.hpp@39114#L35 interprocess_condition::notify_all()].

The problem has been thus-far reduced to incorrect handling of entry/exit conditions in [source:trunk/boost/interprocess/sync/emulation/interprocess_condition.hpp@39114#L79 interprocess_condition::do_timed_wait()]. Additionally, when [source:trunk/libs/interprocess/test/barrier_test.cpp@38329 barrier_test] is run with a small number of threads (such as [source:trunk/libs/interprocess/test/barrier_test.cpp@38329#L32 N_THREADS]=2), and the help of std::cout, we can more easily see that one thread never completely enters the condition variable, or concurrency problems are causing std::cout calls to be useless.

A final note: it appears that Mac OS supports the pthread condition variable. It may be worth allowing the test to run on Mac OS X PPC by using this primitive (known to work). This workaround does not close this ticket, but would solve the problem on that platform and be a valuable optimization."	Bugs	closed	To Be Determined	interprocess	Boost Development Trunk	Regression	fixed