SMP: ISR disable/enable vs. mutual exclustion

[Gedare Bloom]

How much space overhead is the ISR lock? I prefer the solution (1) if
the overhead is not that much.

On Tue, Aug 20, 2013 at 8:59 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> on single processor systems the ISR disable/enable was the big hammer which
> ensured system-wide mutual exclusion.  On SMP configurations this no longer
> works since other processors don't care about disable interrupts on this
> processor and continue to execute freely.
>
> On SMP in addition to ISR disable/enable an SMP lock must be used.  For
> compatibility with single processor configurations I introduced the ISR
> locks.
>
> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicINTRLocks.html
>
> They are currently used for the TOD manager, Termios and the file system
> support.
>
> We need a general review of the RTEMS code base and evaluate every usage of
> ISR disable/enable.  It helps to add proper _Assert() statements to catch
> the hot spots (attached is an example).
>
> This is a high priority issue, since correctness of the system depends on
> this.  This makes SMP and RTEMS currently like playing Russian roulette.
>
> One big issue are the RTEMS chains:
>
> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicChains.html
>
> To make them SMP ready we have two options.
>
> 1. Instead of ISR disable/enable use ISR locks.  Advantage: not interface
> change.  Disadvantage: space overhead for user which only use the
> unprotected routines.
>
> 2. Add a new chain API, e.g. new structure rtems_chain_with_lock which
> provides a chain + ISR lock.  Advantage: you get what you need.
> Disadvantage: API duplication.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>