[andrewp@andypo.net: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines]

[andrewp@andypo.net: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines]

[Andrew Pollard]

The following reply was made to PR libstdc++/5432; it has been noted by GNATS.

From: Andrew Pollard <andrewp@andypo.net>
To: ljrittle@gcc.gnu.org, andrew@andypo.net, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, rodrigc@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: [andrewp@andypo.net: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines]
Date: Wed, 30 Jan 2002 01:31:11 GMT

 ------- Start of forwarded message -------
 Date: Sat, 26 Jan 2002 16:56:52 GMT
 From: Andrew Pollard <andrewp@andypo.net>
 To: ljrittle@gcc.gnu.org, andrew@andypo.net, gcc-bugs@gcc.gnu.org,
    gcc-prs@gcc.gnu.org, rodrigc@gcc.gnu.org, gcc-gnats@gcc.gnu.org
 In-reply-to: <20020124212600.20158.qmail@sources.redhat.com>
 	(ljrittle@gcc.gnu.org)
 Subject: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
 
 Sorry to repost... I hope first attempt didn't make it out of my machine..
 Haven't seen ay responses.... Hope this can make it in for 3.0.4...
 
 Andrew.
 
 >Synopsis: Implementation still not thread-safe on multiprocessor machines
 >
 >State-Changed-From-To: analyzed->feedback
 >State-Changed-By: ljrittle
 >State-Changed-When: Thu Jan 24 13:25:59 2002
 >State-Changed-Why:
 >    Andrew, there were two minor issues with your patch:
 >    (And it took collective thought to figure all this out
 >    so don't feel bad. ;-)
 
 :-) Just glad to have helped.
    
 >    In general, static _Atomic_word should always be init'd
 >    to 0 with C++.  We think g++ follows the init order
 >    rules of C which are tighter than C++ but for C++
 >    non-zero static values may not be init'd until after main()
 >    has run (the only rule says it must be done "before
 >    the related block [scope] is entered" which might be after
 >    threads were started).
  
 I didn't realise this. I had assumed that C++ followed the C rules
 for 'basic' types... 
    
 >    Secondly:
 >    
 >    <       if (--_M_references == 0)  // XXX MT
 >    ---
 >    >       if (__exchange_and_add(&_M_references, -1) == 1)
 >    
 >    is correct (you had == 0).  I.e. assuming it was correct
 >    as written (other than thread-safety) your rewrite had a
 >    memory leak.
 
 Interesting. This is actually a difference between the gcc-3.0 branch
 and the cvs head. I wrote the patch for gcc-3.0.x, and that branch has
 the test
 
     if (_M_references-- == 0)  // XXX MT
 
 So I was right :-) [ But the branch is probably wrong... :-) ] Benjamin
 Kosnik changed the head cvs in late June last year....
 
 >    Other than that, Nathan and I have reviewed the patch;
 >    I have tested it and installed it (that report to
 >    the libstdc++ mailing list).  To be closed after you
 >    confirm MP *-*-linux* system fixed as installed and
 >    then I move it to 3.0.X branch.  Thanks, Loren
 
 Brilliant. I can confirm that the gcc cvs head as of today
 (saturday 26th) compiled and passed the test program on my dual
 processor i686 Redhat7.2 system.
 
 Andrew.
 - --
  Andrew Pollard, ASI/Brooks Automation  | home: andrew@andypo.net
 670 Eskdale Road, Winnersh Triangle, UK | work: Andrew.Pollard@brooks.com
  Tel/Fax:+44 (0)118 9215603 / 9215660   | http://www.andypo.net
 ------- End of forwarded message -------