Fwd: Re: [SMP]: Big Kernel Lock vs ISR_Disable
marta.rybczynska at kalray.eu
Sun Sep 18 15:29:14 UTC 2011
-------- 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
> 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
>>> then the maximum length of disabled interrupts on a single core
>>> other cores and in particular the fairness of the lock. I think this
>>> bad for a real-time system.
>> Yes, when _ISR_Disable/Enable is used with spinlocks the critical
>> length degrades, especially for big locks.
> I guess a spin lock is not a fair lock in general. How do you make sure
> interrupts are not disabled indefinitely?
The implementation is not different that the one by Joel & Jennifer that
can find in score/src/smplock.c:
There is no special effort to assure ordering or bounded time. It can be
but I think you agree that it is not the right moment taking into account
the state of the SMP port.
More information about the users