[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest - Deadlock

[Joshua Cates]

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 
> 
>  
> 
>