This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]