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

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-03-13 20:29:20

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- 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

  Dave, because "violation of the contract" is an exceptional aberrant
case, please throw an exception in each thread which is still
pending on that now-defunct barrier.

> --- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> > 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.

  By the way, for the reason that we want thread-synchronization to be
useful on multiprocessors too (not merely uniprocessors), please do
not pursue that Mutex type-parameter on your template-based design for
rwlocks.  That Mutex template exposes the uniprocessor implementation
guts in a way which would need to be ignored/defeated in
multiprocessor environments which might want very much to use some
underlying high-efficient highly-tuned operating-system primitive for
barrier (or might want to use an operating system-primitive spinlock
instead of some mutex which you are encouraging/mandating).