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

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
> 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
>