[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest.

[Joshua Cates]

Hi Jim,

Yes there is a well known race condition between the mutex unlock and the
wait on the semaphore.  Our implementation is supposed to avoid this
condition (hard to explain in email just now...), but I agree that it is
suspicious because windows is the only platform that uses the code in
question.  One of the many things that makes windows so special is that it
provides neither barrier class nor condition variable implementations.

I'm still having trouble, however, convincing myself that the barrier
class could ever encounter this race condition.  But, as you point out,
this stuff is tricky.

I just found an interesting reference on implementing condition variables
on win32.  Have not had time yet to go through it, but looks like it gives
some concrete solutions and analysis of the windows problem:

 http://www . cs . wustl . edu/~schmidt/win32-cv-1 . html

Maybe we can simply choose one of these Schmidt-Pyarali implementations
for windows.  I'm stressed for time this week, but I can try to look at it
tonight or maybe tomorrow. Let me know what you think.

thanks,

Josh.


______________________________
 Josh Cates			
 Scientific Computing and Imaging Institute
 University of Utah
 Email: cates at sci . utah . edu
 Phone: (801) 587-7697
 URL:   http://www . sci . utah . edu/~cates


On Tue, 26 Aug 2003, Miller, James V (Research) wrote:

> Josh,
> 
> I think the problem with the Barrier is in the condition variable. I dug
> around the net and found a lot of threads on the "incorrect ways of
> implementing condition variables".  My conclusion is that this is very
> tricky.  My best guess right now is that the trouble spot is in
> ConditionVariable::Wait().  From what I read on the net, if the unlocking of
> the external mutex and waiting on the semaphore are performed as an atomic
> operation, then another another thread can jump in between the
> mutex.Unlock() and m_Semaphore.Down() calls.
> 
> There is a condition variable implementation in the boost libraries.  I was
> thinking of looking at that to see if the manner in which they implemented
> condition variables would work for ITK.  In the boost implementation, then
> keep an explicit queue of whose waiting (rather than using the OS) for part
> of the implementation.
> 
> Jim
> 
> 
> 
> > -----Original Message-----
> > From: Joshua Cates [mailto:cates at sci . utah . edu]
> > Sent: Monday, August 25, 2003 6:29 PM
> > To: Miller, James V (CRD)
> > Cc: Insight-Developers; Suyash P. Awate
> > Subject: itkParallelSparseFieldLevelSetImageFilterTest.
> > 
> > 
> > Hi Jim,
> > 
> > We added some additional testing to itkBarrierTest.cxx and 
> > managed to get
> > failure (timeouts) on several Windows platforms.  Looks like 
> > there is a
> > bug somewhere in the Windows implementation.  I will try to debug this
> > locally on my Borland build.  In the meantime, I've removed 
> > the offending
> > code for itkBarrierTest so as not to slow down continuous builds.
> > 
> > Josh.
> > 
> > ______________________________
> >  Josh Cates			
> >  Scientific Computing and Imaging Institute
> >  University of Utah
> >  Email: cates at sci . utah . edu
> >  Phone: (801) 587-7697
> >  URL:   http://www . sci . utah . edu/~cates
> > 
> > 
>