This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations
- From: eric dot norum at usask dot ca
- To: gcc-gnats at gcc dot gnu dot org
- Cc: Andreas Schwab <schwab at suse dot de>
- Date: 5 Feb 2002 21:59:24 -0000
- Subject: libstdc++/5594: m68k/bits/atomicity.h unsafe on some OS/CPU combinations
- Reply-to: eric dot norum at usask dot ca
>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: