Fwd: Re: [SMP]: Big Kernel Lock vs ISR_Disable

[Marta Rybczynska]

-------- Original Message --------
Subject: Re: [SMP]: Big Kernel Lock vs ISR_Disable
Date: Sun, 18 Sep 2011 17:28:05 +0200
From: Marta Rybczynska <marta.rybczynska at kalray.eu>
To: Sebastian Huber <sebastian.huber at embedded-brains.de>

On Wed, 14 Sep 2011 09:59:05 +0200, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>>
>> 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.
> 

Sory for the long reply. I had not used Sparc assembly for years, but the
references tell me of two instructions: ldstub and cas. I cannot see why
*just* the instruction require interrupt disabling. So... I guess you're
writing about the complete lock mechanims implementation. Here, if you
use locks to protect some resource that is accessed from process and
interrupt context, you definitely need a lock that also disables the
interrupts and it is true for all architectures, not just Sparc.

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

The implementation is not different that the one by Joel & Jennifer that
you
can find in score/src/smplock.c:

http://www.rtems.org/viewvc/rtems/cpukit/score/src/smplock.c?revision=1.4&view=markup
There is no special effort to assure ordering or bounded time. It can be
done,
but I think you agree that it is not the right moment taking into account
the state of the SMP port.

Best regards,
Marta