[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest.

[Miller, James V (Research)]

Hey Josh,

I was looking to see if pthreads supports this same thing.  If so, we can
add an argument to Up() which is the value to increase by.



> -----Original Message-----
> From: Joshua Cates [mailto:cates at sci . utah . edu]
> Sent: Tuesday, August 26, 2003 2:25 PM
> To: Miller, James V (Research)
> Cc: Insight-Developers; Suyash P. Awate
> Subject: RE: itkParallelSparseFieldLevelSetImageFilterTest.
> 
> 
> 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
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
>