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 считается ошибкой, поэтому поведение их в подобном случае может быть любым.