Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS.

[Eric Norum <eric.norum@usask.ca>]

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

From: Eric Norum <eric.norum@usask.ca>
To: bkoz@gcc.gnu.org, eric.norum@usask.ca, gcc-bugs@gcc.gnu.org,
        gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS.
Date: Tue, 2 Apr 2002 09:32:17 -0600

 On Monday, April 1, 2002, at 08:56 PM, bkoz@gcc.gnu.org wrote:
 
 > Synopsis: Sparc atomicity.h routines can lock up on some OS.
 >
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: bkoz
 > State-Changed-When: Mon Apr  1 18:56:21 2002
 > State-Changed-Why:
 >     I guess you'll have to use heavier-weight locks for these OS's. Can 
 > you think of another solution? I cannot.
 >
 >     Note this is an issue with all the cpu/atomicity.h files, not just 
 > sparc, right?
 >
 >
 
 No, it's not an issue for architectures which provide hardware support 
 for this operation.  Some 68k family members have a `compare and set' 
 instruction, the 80x86 family has the lock prefix,  etc.   The sparc 
 routine appears to be the only one that uses a spin lock to protect the 
 operation and is thus the only code that is at risk in a 
 strict-preemptive OS environment.   Even the sparc64 code has no spin 
 lock.  I don't know enough about the sparc architecture to be able to 
 say if the any of the techniques used in the other source files could be 
 used to replace the existing sparc code.
 
 
 --
 Eric Norum <eric.norum@usask.ca>
 Department of Electrical Engineering
 University of Saskatchewan
 Saskatoon, Canada.
 Phone: (306) 966-5394   FAX:   (306) 966-5407