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