Status of SMP Work

[Sebastian Huber]

Hello,

I would like to summarize the current status of the SMP work that is 
already done in RTEMS.  Please correct me if something is wrong or 
missing.  An interesting document about real-time systems on SMP is the 
dissertation from Björn B. Brandenburg 
(http://www.cs.unc.edu/~bbb/diss/).  He mentions also RTEMS as a 
classical uni-processor real-time system.

1. We have now per-CPU information so that some state can be maintained 
on a per-CPU basis:

http://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/percpu.h

Access to several global variables has been encapsulated with a function.

2. We have now a configurable scheduler (examples are FP, EDF, CBS) 
which makes it possible to develop SMP capable scheduler more easily.

3. We have a first support for spin locks. The current implementation is 
not suitable for real-time applications:

http://git.rtems.org/rtems/tree/cpukit/score/src/smplock.c

Here interrupts are disabled before the loop and thus the disable 
interrupt time on this core is unbounded.  We need also a lock with FIFO 
properties like a MCS lock.

4. Support for atomic operations is a current GSoC project and now also 
part of the C and C++ standard.

5. There are a couple of PRs with an unknown status, like

https://www.rtems.org/bugzilla/show_bug.cgi?id=1946
https://www.rtems.org/bugzilla/buglist.cgi?quicksearch=smp

6. It seems that in the current SMP work the sections covered by 
_Thread_Disable_dispatch() and _Thread_Enable_dispatch() produce a 
critical section that is protected by a giant lock:

http://git.rtems.org/rtems/tree/cpukit/score/src/threaddispatchdisablelevel.c

These critical sections are pretty huge and I don't think this scales 
well with an increasing processor count. Why was it not possible to move 
the thread dispatch disable level into the per-CPU information and use 
_ISR_Disable()/_ISR_Enable() as the giant lock?  This has the benefit 
that we can probably use existing interrupt and exception code.  It 
makes it also possible to gradually replace the 
_ISR_Disable()/_ISR_Enable() sections with more specific locks, e.g. one 
for a basic semaphore operation and one for the general blocking path.  
I think only thread restart and delete operations are problematic here.  
Did I miss something important?  What lead to the decision of a global 
thread dispatch disable level?

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
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.