From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-02-18 09:21:40
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
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.
> - Volodya
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk