[boost] Re: Moving Boost.Thread barrier from thread_dev to HEAD

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-18 02:04:00

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.

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