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

[Sergey Vlasov]

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 считается ошибкой, поэтому поведение их в подобном
случае может быть любым.
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : http://lists.altlinux.org/pipermail/devel-kernel/attachments/20060619/04b39415/attachment.bin