spin_lock_irqsave only re-enables interrupts while spinning on some archs?

spin_lock_irqsave only re-enables interrupts while spinning on some archs?

[Chuck Ebbert]

On some architectures, spin_lock_irqsave() re-enables interrupts when
spinning while waiting for the lock to become available.  The list
of archs includes i386, powerpc and ia64.  Others leave interrupts
disabled while spinning (x86_64, arm, alpha).  They just define
__raw_spin_lock_flags to be the same as __raw_spin_lock.  (And
because predication is so efficient, ia64 does the opposite:
it uses __raw_spin_lock_flags for everything -- a neat trick.)

Shouldn't there be a standard way of doing this?  Is there any practical
difference in behavior?

-- 
Chuck
"Penguins don't come from next door, they come from the Antarctic!"

Re: spin_lock_irqsave only re-enables interrupts while spinning on some archs?

[linux-os (Dick Johnson)]

On Mon, 6 Mar 2006, Chuck Ebbert wrote:

> On some architectures, spin_lock_irqsave() re-enables interrupts when
> spinning while waiting for the lock to become available.  The list
> of archs includes i386, powerpc and ia64.  Others leave interrupts
> disabled while spinning (x86_64, arm, alpha).  They just define
> __raw_spin_lock_flags to be the same as __raw_spin_lock.  (And
> because predication is so efficient, ia64 does the opposite:
> it uses __raw_spin_lock_flags for everything -- a neat trick.)
>
> Shouldn't there be a standard way of doing this?  Is there any practical
> difference in behavior?
>
> --
> Chuck
> "Penguins don't come from next door, they come from the Antarctic!"

I think you just discovered a bug! I haven't looked at the
spin-locks for over a year. If the interrupts are enabled
during the spin, a lower priority task may never get the
lock! A deadlock is not only possible, but probable. It needs
to just spin until the lock is given up. That's why they
are called spin-locks.

The __raw_spin_lock_string_flags looks completely wrong! The
interrupts on the local CPU must be disabled first and left
alone (off). Then the lock should be taken, spinning until
it succeeds.

The code decrements the lock variable over-and-over again
on each jump back to the 1: label. Since the interupts
are enabled when the lock-variable is tested after the
3: label,  the byte will eventually wrap so the "got the
lock" condition occurs even if the holder of the lock
never releases it! This is not good code even though it
might accidentally work.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.50 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.