[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest.

Joshua Cates cates at sci . utah . edu
Tue, 26 Aug 2003 14:07:49 -0600 (MDT)


Excellent.  How important is it to support these other Win systems?  At
this point it is not clear to me whether it is even feasible to support
condition variables on older windows systems.

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 checked in the implementation of condition variables for Win32 systems 
> you referenced at 
> 
>   http://www . cs . wustl . edu/~schmidt/win32-cv-1 . html
> 
> This implementation fixes the problems I had with the Barrier class. 
> 
> The caveat is that this implementation will only build on systems that 
> are based on WinNT 4.0 or greater (WinNT 4.0, Win2000, and WinXP).  
> So Win95, Win98, and WinME systems are not supported.
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: Joshua Cates [mailto:cates at sci . utah . edu]
> > Sent: Tuesday, August 26, 2003 12:49 PM
> > To: Miller, James V (Research)
> > Cc: Insight-Developers; Suyash P. Awate
> > Subject: RE: itkParallelSparseFieldLevelSetImageFilterTest.
> > 
> > 
> > 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
> > > > 
> > > > 
> > > 
> > 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk . org
> http://www . itk . org/mailman/listinfo/insight-developers
>