SMP: ISR disable/enable vs. mutual exclustion

[Sebastian Huber]

Hello Pavel,

thanks for your interesting pointers.

On 08/28/2013 04:31 PM, Pavel Pisa wrote:
[...]
> The containers basic API should be without locking.
> You usually need something like atomic extract from one list
> and insert to the other list. And you waste additional
> locking in list remove/insert when you have to provide
> lock to make operations sequence atomic.
> There is usually good/natural place where lock belongs
> in such cases. Or you do not want to use IRQ+spin-lock
> there but whole sequence is protected by mutex (should be
> with priority inheritance for each case).
>
> This is how Linux kernel defines containers and data structures
> too. Problem is that it is really very hard to switch
> to unlocked containers when code in some places and sequences
> depends on locking in containers.
[...]

I completely agree with you.

My short term goal is to get a correct working SMP support with no negative 
impact for the existing RTEMS users.  Here we have to deal with the existing 
RTEMS chains.  This is the last item on my short term list.

The next step is to work on missing essential features like thread deletion. 
Once this is done the hard work can begin.  This is the introduction SMP 
real-time schedulers and corresponding locking protocols.  Here we have to 
review also all sequences that are currently protected by the Giant lock 
(roughly equal to the thread dispatch disable/enable) and introduce fine 
grained locking or alternatives to locking.

Some parts in RTEMS don't scale to many processors at all, e.g. the delta 
chains in the watchdog.

Another big issue will be the debugging and tracing of applications.  How can I 
figure out why my system with one address space and X processors crashed?

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