Vladimir Prus wrote:
Michael Glassford wrote:
m_generation = (m_generation + 1) % 2;
Which would be simpler that checking for overflow on maximum integer value. It's still interesting to know if processors which trap on overflow exists nowdays...
For certain (mis)uses of the barrier class, that seems to me like it could lead to a race condition: if enough threads (re)enter the barrier before all of the threads from the previous generation finish exiting it, when the old threads wake up they will see the condition variable's condition reset to the same value as when they first entered and will wait on the conditional variable again (without first decrementing m_count, which is even worse).
Actually, to get enough threads to reenter barrier while some threads are still inside, you need fresh threads on the next barrier. IOW, threads A, B and C wait on barrier. A gets through and spawns B' and C'. Then A, B' and C' wait on barrier, get though, and leave B and C stuck on condition wait forever.
True, I realize that. Or you could simply create a barrier that blocks until it reaches, say, 5 threads and then send 10 threads through it. In a worst case scenario, 4 of the first 5 threads to wait on the barrier could get stuck there permanently. As I said, this would be a misuse of the barrier class, but it's almost certain someone will do it--and I suppose they may even have a legitimate reason for doing so.
Well, I don't know if this is proper use or misuse, but anyway, if unsiged does not overflow, there's no problem to solve in the first place.
True enough.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost