[SMP]: Big Kernel Lock vs ISR_Disable

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Sep 14 07:59:05 UTC 2011


On 09/13/2011 10:46 PM, Marta Rybczynska wrote:
> Hello!
>
> On Tue, 13 Sep 2011 09:29:20 +0200, Sebastian Huber
> <sebastian.huber at embedded-brains.de>  wrote:
>>
>> Does the _ISR_Disable/Enable still disable/enable interrupts on the
>> executing
>> core?  I suppose the lock used in _Lock/Unlock_Critical_Section uses a
>> spin
>> lock and thus disables also the interrupts on the executing core?  Is it
> a
>> fair
>> lock?
>>
>
> Yes, _ISR_Disable/Enable disables/enables interrupts on the local core.
> The lock in _Lock/Unlock_Critical_Section is a recursive spinlock that
> does not change interrupt state.

On the PowerPC spin locks without disabling interrupts on the executing core 
are problematic.  You have to make sure that thread dispatching on this core is 
disabled if you want to obtain a spin lock without disabling interrupts. 
Otherwise you may end up in a dead lock.

>
>
>> Suppose the _ISR_Disable() still disables interrupts on the executing
>> core,
>> then the maximum length of disabled interrupts on a single core depends
> on
>> all
>> other cores and in particular the fairness of the lock.  I think this is
>> very
>> bad for a real-time system.
>>
> Yes, when _ISR_Disable/Enable is used with spinlocks the critical section
> length degrades, especially for big locks.

I guess a spin lock is not a fair lock in general.  How do you make sure that 
interrupts are not disabled indefinitely?

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



More information about the users mailing list