Re: [d-kernel] -немного недопонял, - В kernel 2.6.16 теперь ждущие блокировки spinlock() не работают?] (Sergey Vlasov)

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Mon, Jun 19, 2006 at 09:20:20AM +0000, gosha wrote:
> >Значит, этот тест был выполнен на ядре *-up, где spin_lock()
> >действительно ничего не делает.  Spinlock используются только на SMP
> >для синхронизации между несколькими процессорами.  Код, пытающийся
> >рекурсивно захватить один и тот же spinlock на одном процессоре,
> >недопустим - это гарантированный deadlock.
> 
> >  И в include/linux/spinlock*.h ничего похожего на разблокировку/ блокировку ....
> 
> >Все реализации spinlock архитектурно-зависимые, и поэтому лежат в
> >include/asm-*.
[...]
> Т.е. для однопроцессорных систем ждущие блокировки spinlock() и не
> должны ничего делать в принципе?? Судя по коду это так, но это как бы
> нелогично...

И что здесь нелогичного?  Блокировки этого типа предназначены только для
синхронизации на SMP, при наличии только одного процессора ждать просто
нечего.

>    Напр касок кода /kernel/irq/hahdle.c :
> -------------------------------------------------------
> /* do_IRQ handles all normal device IRQ's (the special SMP cross-CPU interrupts have their own specific handlers). */
> fastcall unsigned int __do_IRQ(unsigned int irq, struct pt_regs *regs)
[...]
spin_lock здесь обеспечивает защиту от модификации данных другими
процессорами; предполагается, что на одном и том же процессоре __do_IRQ()
не может быть вызвана рекурсивно для обработки того же самого прерывания.

> Также все работает в режиме CONFIG_DEBUG_SPINLOCK :
[...]
Да, это сделано специально, чтобы была хоть какая-то возможность
отлавливать некоторые ошибки в использовании spinlock без SMP.

> Так и должно быть??? У меня во всех книжках по линуксу написано, что это
> ждущая блокировка и оно должно работать как мутекс!

spinlock и mutex в Linux - существенно разные типы блокировок.  Блокировки
типа semaphore/mutex могут использоваться только в том случае, если
допускается переход в состояние ожидания (sleep) - в случае, если mutex
уже занят другим процессом, выполняется переключение контекста на один из
других процессов, готовых к выполнению.  В случае spinlock выполняется
просто ожидание освобождения в цикле без переключения контекста - поэтому
spinlock может использоваться, например, в обработчике прерываний.

Вообще, если в однопроцессорной системе процессор ожидает освобождения
spinlock-а, освободить его теоретически мог бы только какой-то обработчик
прерывания (если прерывания в этот момент разрешены), но подобное
использование spinlock считается ошибкой, поэтому поведение их в подобном
случае может быть любым.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]