[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest.
Joshua Cates
cates at sci . utah . edu
Tue, 26 Aug 2003 12:36:37 -0600 (MDT)
Unfortunately I don't think it does. sem_post() seems to be the only
option for incrementing the count.
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:
> 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>