[Insight-developers] RE: itkParallelSparseFieldLevelSetImageF ilterTest - Deadlock

[Miller, James V (Research)]

Perhaps the issue is in the semaphore.  I am digging through the MS docs
figure out if the count of the semaphore needs to be "reset".  If the
semaphore
is getting reused, it may never be returning to the nonsignaled state.



> -----Original Message-----
> From: Joshua Cates [mailto:cates at sci . utah . edu]
> Sent: Friday, August 15, 2003 3:21 PM
> To: Miller, James V (Research)
> Cc: 'Insight-developers (E-mail)'; Suyash P. Awate
> Subject: Re: [Insight-developers] RE:
> itkParallelSparseFieldLevelSetImageFilterTest - Deadlock
> 
> 
> I can't find any flaws in the logic of the Barrier implementation that
> would allow this particular race condition.  See if you agree.  The
> relevent code for Windows (unless you are using pthreads?) is:
> 
> void Barrier::Wait()
> {
>   m_Mutex.Lock();
>   m_NumberArrived++;
>   if ( m_NumberArrived == m_NumberExpected )
>     {
>     // Clear all blocked threads
>     m_NumberArrived = 0;
>     m_ConditionVariable->Broadcast();
>     }
>   else
>     {
>     // Block this thread
>     m_ConditionVariable->Wait( &m_Mutex );
>     }
>   m_Mutex.Unlock();
> }
> 
> void ConditionVariable::Broadcast()
> {
>   m_Lock.Lock();
>   while ( m_NumberOfWaiters > 0 )
>     {
>       m_NumberOfWaiters--;
>       m_Semaphore->Up();
>     }
>   m_Lock.Unlock();
> }
> 
> void ConditionVariable::Wait(SimpleMutexLock *mutex)
> {
>   m_Lock.Lock();
>   m_NumberOfWaiters++;
>   m_Lock.Unlock();  
> 
>   mutex->Unlock();
>   m_Semaphore->Down();
>   mutex->Lock();
> }
> 
> 
> From the mutexing, if a thread is in ConditionVariable::Broadcast()  
> (releasing the barrier), then no other thread may block on 
> that barrier
> until all threads have been released.
> 
> Can you verify that all 3 threads for this test are being successfully
> created?  The situation you describe would result if, for some reason,
> windows failed to create one or more of the requested threads and
> itk::MultiThreader, for some reason, failed to throw an exception.
> 
> Another issue that may relate:  I have observed on my windows 
> machine that 
> itkMultiThreader will hang when trying to spawn more than 4 
> threads.  This 
> happens sporadically with VC60 builds and always with Borland 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
> 
> 
> On Fri, 15 Aug 2003, Miller, James V (Research) wrote:
> 
> > I think this might be related to the use of the Barrier 
> class.  A single
> > instance of the barrier object is used to synchronize the 
> code in multiple
> > places.  I think what may be happening in the single 
> processor case is that
> > once the barrier is satisfied, the threads start unrolling 
> from the barrier
> > and continue on.  I think one thread is making it to the 
> next barrier before
> > all the threads of finished unrolling from the first barrier.  
> >  
> > (My current best guess.)
> >  
> >  
> > 
> > -----Original Message-----
> > From: Miller, James V (Research) 
> > Sent: Friday, August 15, 2003 11:06 AM
> > To: Josh Cates (E-mail); Insight-developers (E-mail)
> > Subject: itkParallelSparseFieldLevelSetImageFilterTest - Deadlock
> > 
> > 
> > This test gets into a deadlock on my uniprocessor PC using 
> Visual Studio
> > .NET.
> >  
> >  
> > 
> > Jim Miller 
> > _____________________________________
> > Visualization & Computer Vision
> > GE Research
> > Bldg. KW, Room C218B
> > P.O. Box 8, Schenectady NY 12301
> > 
> > millerjv at research . ge . com <mailto:millerjv at research . ge . com> 
> > 
> > james . miller at research . ge . com
> > (518) 387-4005, Dial Comm: 8*833-4005, 
> > Cell: (518) 505-7065, Fax: (518) 387-6981 
> > 
> >  
> > 
> > 
>