[Insight-developers] _GLIBCXX_DEBUG is not thread safe.

[Hans Johnson]

Sean,

I do not have access to gcc4.3 (or at least do not have time to install and
test it).  

The problem is that these programs get "stuck" in the mutex lock and never
complete.

I do not require those flags for my work, so I just removed them.

Hans
-- 
Hans J. Johnson, Ph.D.
Hans-johnson at uiowa.edu

278 GH
The University of Iowa
Iowa City, IA 52241
(319) 353 8587


> From: Sean McBride <sean at rogue-research.com>
> Organization: Rogue Research
> Date: Thu, 27 Mar 2008 12:10:48 -0400
> To: Hans Johnson <hans-johnson at uiowa.edu>, ITK <insight-developers at itk.org>
> Subject: Re: [Insight-developers] _GLIBCXX_DEBUG  is not thread safe.
> 
> On 3/27/08 9:30 AM, Hans Johnson said:
> 
>> I wanted to get this information out on the developer list so that others
>> would see it.
>> 
>> _GLIBCXX_DEBUG  does not seem to be thread safe.
> 
> A search of the gcc bugbase reveals several threading issues, yes:
> <http://gcc.gnu.org/bugzilla/query.cgi>
> 
> For example, it is known to be not thread safe with gcc 3.3 (where the
> feature was introduced).  See:
> <http://gcc.gnu.org/ml/libstdc++/2004-09/msg00170.html>
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664>
> 
> You might also want to google "<rdar://4417672>".
> 
>> Code consistently in the pthread mutex lock when using "-g -D_GLIBCXX_DEBUG"
>> at line 302 of InsightToolkit/Algorithms/itkFastMarchingImageFilter.txx
>> =====================
>> 299   while ( !m_TrialHeap.empty() )
>> 300     {
>> 301     // get the node with the smallest value
>> 302     node = m_TrialHeap.top();
>> 303     m_TrialHeap.pop();
>> =====================
>> -- AND --
>> At line 141 of InsightToolkit/BasicFilters/itkMedianImageFilter.txx
>> =====================
>> 139       // get the median value
>> 140       const typename std::vector<InputPixelType>::iterator
>>                       medianIterator = pixels.begin() + medianPosition;
>> 141       std::nth_element(pixels.begin(), medianIterator, pixels.end());
>> 142       it.Set( static_cast<typename OutputImageType::PixelType>
>>                        (*medianIterator) );
>> =====================
>> _L_mutex_unlock_153,  FP=bfffd3c8
> 
> I'm not sure I understand... what is the symptom you see with ITK?  Are
> you sure it's not an ITK bug?
> 
> Can you try with gcc 4.3 on linux?
> 
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>