Re: Question about spin-lock/interrupt/ipl interaction.

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 27 Jan 2011, at 15:18 , Matt Thomas wrote:
> Why the latter is a violation, it seems wrong to me for a interrupt to return 
> to the code that was interrupted at a different ipl from which it was 
> invoked.  
> 
> Should the spin-locks semantics be modified for interrupt usage?

For what it's worth my bet is that there is no exactly right answer to
that.

Interrupting a spin-lock costs more than a "normal" interrupt since
it extends the time that other CPUs might waste themselves waiting
for the lock to be released.  While there's an argument which says
that lower priority tasks shouldn't block higher priority interrupts
there's also a counter-argument which says that spin-locks are special
and you really shouldn't allow them to be interrupted at all since
the cost to the processor complex as a whole is minimized if the code
inside the lock runs uninterrupted until the lock is released.

So the current behaviour may not be beautiful but seems like a
middle ground between the extremes.  It doesn't initially
block higher-priority interrupts, but it bounds the number it'll
take before it lets the code in the lock run to completion
without further interrupts.  Dropping the IPL after each interrupt
would leave no bound on how long the spin-lock could potentially
be held, hence violating the premise that spin-locks should only
be used for code sequences that will complete in a short time and
providing no bound on how much of the other CPUs' time might be
wasted doing nothing while waiting for one.

Dennis Ferguson