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.hu...@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.hu...@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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
