Fix:
With the attached patch, the attached program 'always' seems to work (I had it in a while loop running for about an hour...)

I don't make any guarantees for the correctness of the patch, but it definitely addresses some of the 'XXX MT' issues in the source code (eg using _Atomic_word, __atomic_add, __exchange_and_add and a lock)

The gcc-3.1 cvs code is very similar, if not the same...

Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-Why: Taking at Ben's request.

State-Changed-From-To: open->analyzed
State-Changed-Why: Wacking patch into final shape (addressing issue of only
    zero PODs being guaranteed to be initiallized before
    main() starts).

State-Changed-From-To: analyzed->feedback
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. ;-)
    
    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).
    
    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.
    
    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

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

State-Changed-From-To: feedback->closed
State-Changed-Why: Fixed in recent gcc 3.1 snapshots.

From: Andrew Pollard <andrewp@andypo.net>
To: rodrigc@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc: andrew@andypo.net, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   ljrittle@gcc.gnu.org
Subject: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
Date: Mon, 18 Feb 2002 23:34:46 GMT

 >Synopsis: Implementation still not thread-safe on multiprocessor machines
 >
 >State-Changed-From-To: feedback->closed
 >State-Changed-By: rodrigc
 >State-Changed-When: Sun Feb 17 18:54:57 2002
 >State-Changed-Why:
 >    Fixed in recent gcc 3.1 snapshots.
 >
 >http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5432
 
 Cheers. I have verified that the 3.1 source "works as expected".
 
 Shame it couldn't make it into gcc-3.0.4, I'll just have to patch locally
 once gcc-3.0.4 is out...
 
 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