[Insight-developers] RE: itkParallelSparseFieldLevelSetImageFilterTest - Deadlock

Joshua Cates cates at sci . utah . edu
Fri, 15 Aug 2003 12:17:50 -0600 (MDT)


Hi Jim,

I'll look into this.  The Barrier class should be preventing this
situation... but it is possible that there is a bug somewhere in the
ConditionVariable implementation that permits it.  A bug in the Mutex 
class could also permit this condition, but seems less likely.


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