interprocess_condition (emulated) hangs after notify_all().

[atack2@…]

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.

[atack2@…]

I intend to solve this problem. It appears, however, that without a login, I cannot own this ticket. That's fine; I'll just watch it.

[Ion Gaztañaga]

Mac OS supports the pthread condition variable, but does not support process-shared condition condition variables, so we can't use it for Boost.Interprocess.

[anonymous]

Ion: This was fixed in revision [39957]. How in the world did you figure out that bug?

[atack2@…]

Replying to anonymous:

Ion: This was fixed in revision [39957]. How in the world did you figure out that bug?

Sorry for the anonymous comment; this was from Tack.

[Ion Gaztañaga]

All PPC regressions were failing so I started revising the only platform-dependent file related to interprocess_condition. A bit of intuition and a lot of work ;-)

[atack2@…]

You could re-include the [source:trunk/libs/interprocess/test/barrier_test.cpp@38329 barrier test], now that this is solved. Just being notice-y.