[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest.

[Joshua Cates]

Jim,

I believe that lReleaseCount is what you want. 

BOOL ReleaseSemaphore(
  HANDLE hSemaphore, 
  LONG lReleaseCount, 
  LPLONG lpPreviousCount 
);

In itkSemaphore.cxx::Up() you'll see a call to Release(m_Sema, 1, 0), 
which increments by one.

See the url:

http://msdn . microsoft . com/library/default . asp?url=/library/en-us/wcemain4/html/_wcesdk_semaphore_objects . asp

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, 
> 
> Does a pthread semaphore provide an API to adjust the semaphore value 
> by more than 1?  Some of these Win32 condition variable implementations
> require incrementing the semaphore by more than 1.  I am trying to decide
> whether to much the itkSemaphore class with this or just put in straight
> Win32 code in the condition variable.
> 
> I tried (a port of) the boost condition variable and it also deadlocked.
> I am going to try one of Schmidt's solutions now.
> 
> 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
> > > > 
> > > > 
> > > 
> > 
>