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