Re: Threads: Barrier destuction, ??? for references

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-13 16:12:14

--- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> I'm trying to define what could/should happen if a barrier is 
> destroyed while other threads are still wait()ing on the barrier.
> 
> POSIX threads state that the impact on those threads is undefined.
> 
> I wanted to do some more reading on cancellation mechanics for 
> barriers to see if some solution that would throw a controlled 
> exception out of wait() in this case is possible.
> 
> Most of the references I can find to barriers on the web are from 
the 
> massively-parallel architecure field, and implementation strategies 
> for these architectures....
> 
> Does anyone know of the "seminal" paper for this concept?

No, but I can offer an opinion.  This is a violation of the contract, 
and thus *should* result in undefined behavior.  This is no different 
then what happens if there are threads trying to lock a mutex when 
you destroy it, which is, rightfully I believe, defined as undefined 
behavior in both POSIX and Boost.Threads.  On Windows platforms it 
results in a return from WaitForSingleObject indicating 
an "abandoned" mutex, but there's a lot of information you can find 
by doing a google search that shows why this is a bad idea.  You 
can't make use of this "error" in any meaningful way.  I believe that 
the same logic applies to the barrier.

Bill Kempf