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

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

[davem]

Synopsis: Sparc atomicity.h routines can lock up on some OS.

State-Changed-From-To: analyzed->feedback
State-Changed-By: davem
State-Changed-When: Tue Oct  1 22:14:02 2002
State-Changed-Why:
    I can add the IRQ disabling code for v7 if people
    tell me what an appropriate ifdef check
    would be. Would it work if either of __rtems___ __vxWorkd__ or __embedded__ is set?  Can I be guarenteed that I will
    be running in privileged mode if one of those ifdefs
    are set?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4367

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

[davem]

Synopsis: Sparc atomicity.h routines can lock up on some OS.

State-Changed-From-To: feedback->closed
State-Changed-By: davem
State-Changed-When: Sat Nov  2 01:38:08 2002
State-Changed-Why:
    Indeed, no constructive responses to my queries, this
    bug is dead.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4367

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

[bkoz]

Synopsis: Sparc atomicity.h routines can lock up on some OS.

Responsible-Changed-From-To: unassigned->davem
Responsible-Changed-By: bkoz
Responsible-Changed-When: Fri Nov  1 18:05:44 2002
Responsible-Changed-Why:
    Yours. I think you can close this.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4367

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Eric Norum <eric.norum@usask.ca>
Cc: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS.
Date: Tue, 2 Apr 2002 13:49:23 -0800

 On Tue, Apr 02, 2002 at 09:32:17AM -0600, Eric Norum wrote:
 > 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.
 
 Not for sparc v7.
 
 
 r~

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

[Eric Norum]

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
 

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
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 00:08:05 -0800

 On Tue, Apr 02, 2002 at 02:56:22AM -0000, bkoz@gcc.gnu.org wrote:
 >     I guess you'll have to use heavier-weight locks for these OS's.
 >     Can you think of another solution? I cannot. 
 
 Generally for these targets you turn off interrupts.  See
 the m68k atomicity.h, for instance.
 
 >     Note this is an issue with all the cpu/atomicity.h files,
 >     not just sparc, right?
 
 No, only those cpu's that have to use spinlocks instead of
 e.g. an atomic-add, compare-and-exchange, or load-locked
 instruction.
 
 Of those listed in config/*, Sparc v7/v8, m68000, MIPS I,
 and PA are affected.
 
 MIPS I is an odd-ball because some operating systems (eg Linux)
 provide emulation for the MIPS II ll/sc instructions.  Currently
 our atomicity.h file assumes MIPS II.
 
 
 r~

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

[bkoz]

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

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4367

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

[Phil Edwards]

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

From: Phil Edwards <pedwards@disaster.jaj.com>
To: eric.norum@usask.ca
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS.
Date: Thu, 20 Sep 2001 11:23:25 -0400

 On Thu, Sep 20, 2001 at 02:50:01PM -0000, eric.norum@usask.ca wrote:
 > >Description:
 > The sparc version of the routines in atomicity.h can lock up
 > on operating systems which provide strict priority-based
 > scheduling (e.g. vxWorks, pSOS+, eCOS, RTEMS).  Here's the
 > scenario:
 > 1) Low priority task enters __exchange_and_add and sets
 >    the lock.
 > 2) While low-priority task is still active in
 >    __exchange_and_add a higher-priority task preempts.
 > 3) The higher-priority task enters __exchange_and_add and
 >    enters an infinite loop trying to set the lock.
 
 A classic case of priority inversion.  Wow.  I never imagined I'd be
 involved in one of those.  :-)
 
 One of the various Mars rover-type vehicles got locked up by priority
 inversion, I recall.
 
 -- 
 Would I had phrases that are not known, utterances that are strange, in
 new language that has not been used, free from repetition, not an utterance
 which has grown stale, which men of old have spoken.
                                      - anonymous Egyptian scribe, c.1700 BC

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

[eric.norum]

>Number:         4367
>Category:       libstdc++
>Synopsis:       Sparc atomicity.h routines can lock up on some OS.
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 20 07:56:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Eric Norum
>Release:        gcc-3.0
>Organization:
>Environment:
Real-time OS environments (e.g. vxWorks, pSOS+, eCOS, RTEMS)
>Description:
The sparc version of the routines in atomicity.h can lock up
on operating systems which provide strict priority-based
scheduling (e.g. vxWorks, pSOS+, eCOS, RTEMS).  Here's the
scenario:
1) Low priority task enters __exchange_and_add and sets
   the lock.
2) While low-priority task is still active in
   __exchange_and_add a higher-priority task preempts.
3) The higher-priority task enters __exchange_and_add and
   enters an infinite loop trying to set the lock.
>How-To-Repeat:

>Fix:
None that I can think of, unfortunately!
>Release-Note:
>Audit-Trail:
>Unformatted: