Re: libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

Re: libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

[rodrigc]

Synopsis: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Mon Feb 18 17:18:16 2002
State-Changed-Why:
    http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00942.html

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

Re: libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

[rodrigc]

Synopsis: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

State-Changed-From-To: open->feedback
State-Changed-By: rodrigc
State-Changed-When: Sun Feb 17 19:35:35 2002
State-Changed-Why:
    Does the following patch address your concerns?
    http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00942.html
    
    It has been recently applied to the main CVS head.

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

libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations

[eric.norum]

>Number:         5594
>Category:       libstdc++
>Synopsis:       m68k/bits/atomicity.h unsafe on some OS/CPU combinations
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 05 14:06:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Eric Norum <eric.norum@usask.ca>
>Release:        Post 3.0.3
>Organization:
>Environment:
Strict-priority-based systems (RTEMS, vxWorks, etc.)
>Description:
The current CVS version of gcc has attempted to address the
problem with a missing CAS instruction on some M68k family
members.  I am concerned about the way this has been handled
though.  Here is how the code now looks:

#if defined(__mc68020__) || defined(__mc68030__) \
    || defined(__mc68040__) || defined(__mc68060__)
        Use CAS
#elif !defined(__mcf5200__) && !defined(__mcf5300__)
        Use TAS and jbne
#else
// These variants do not support any atomic operations at all.
// The best we can hope for is to disable interrupts, which we
// can only do from supervisor mode.

#if defined(__rtems__) || defined(__vxWorks__) || defined(__embedded__)

        disable interrupts, perform operation, restore interrupts
#else
        warn about non-atomic operations
#endif
#endif

The problem with this is that the TAS/JBNE that's used for
68000, 68010, CPU32, etc. is inherently unsafe in a strict-
priority environment like RTEMS.  Here's why:
   Low priority task enters __exchange_and_add.
   Low priority task executes TAS.
   High priority task preempts before low-priority task releases lock.
   High priority task enters __exchange_and_add
   High priority task enters infinite loop doing TAS/JBNE
Loop is infinite because low-priority task never gets a
chance to run and release the lock.

This problem is present in the sparc implementation of this
routine, too.
>How-To-Repeat:

>Fix:
I believe that the order of the conditional compiles should
be changed so that the RTEMS et al. clause takes precedence
over the ~mcf5200 et al. clause:

#if has_cas
    use CAS loop
#elif RTEMS/vxWorks/embedded
    use interrupt disable/restore
#elif has TAS
    use TAS/JBNE loop
#else
    emit warning
#endif
>Release-Note:
>Audit-Trail:
>Unformatted: