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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-02-17 08:33:26

Vladimir Prus wrote:

> Michael Glassford wrote:
> 
> 
>>One potential problem that I am aware of is that it is possible for the
>>m_generation counter (see barrier.cpp) to overflow on systems that
>>detect overflow of integer addition instead of wrapping (I assume there
>>are such systems though I've never used one). Is it worthwhile checking
>>for this and forcing wrapping in code?
> 
> 
> I think that barrier will work just fine with a binary flag, as opposed to
> integer generation counter. In which case you can do
> 
>    flag = !flag;
> 
> or 
> 
>     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).

Theoretically this could happen with the current implementation too, but 
it would require a lot more threads going through the barrier!

> - Volodya