spin_lock是否只对多处理器起作用
spin_lock是否只对多处理器起作用 在编译内核的时候不指定SMP选项，spin_xxx的相关操作都被架空
在LINUX_SOURCE/include/linux/spinlock.h中写的很清楚
/*
* If CONFIG_SMP is set, pull in the _raw_* definitions
*/
...
...
/*
* If CONFIG_SMP is unset, declare the _raw_* definitions as nops
*/ 不是
<<linux device drivers 3rd>>中对于spinlock有介绍的。
当对spinlock加锁时，如果获取不到共享资源，进程会发生死循环，决不释放CPU。
但可以在此时通过CPU的硬件中断，完成对共享资源的释放，从而解决死锁。
<<linux device drivers 3rd>>中对于spinlock有介绍的。
当对spinlock加锁时，如果获取不到共享资源，进程会发生死循环，决不释放CPU。
但可以在此时通过CPU的硬件中断，完成对共享资源的释放，从而解决死锁。
原来是这样，刚看了LDD 3rd 第5章中有关spinlock的介绍才真正明白这是它是怎么一回事。
对于非SMP，非抢占式内核，spin相关的操作才会被设置为nop；
但对运行于单CPU的抢占式(preemption在编译是可配置)内核的并发处理仍然需要执行spinlock操作。
底下为相关说明的原文:
Spinlocks are, by their nature, intended for use on multiprocessor systems, although
a uniprocessor workstation running a preemptive kernel behaves like SMP, as far as
concurrency is concerned. If a nonpreemptive uniprocessor system ever went into a
spin on a lock, it would spin forever; no other thread would ever be able to obtain
the CPU to release the lock. For this reason, spinlock operations on uniprocessor systems
without preemption enabled are optimized to do nothing, with the exception of
the ones that change the IRQ masking status. Because of preemption, even if you
never expect your code to run on an SMP system, you still need to implement proper
locking.
LINUX的内核是非抢占式的
那么在其内核态下运行的程序不会被调度
但是如果内核态程序自己调用schedule()的话 会出现什么情况(如果不行 内核进程通过什么方法自愿交出CPU使用权）
还有，非抢占是不是通过关中断来实现的。 如果是的话，那时钟中断怎么进行。
而且，如果某个内核态程序出现了诸如死循环的问题 是不是也就没有办法通过其他的方法进行补救了呢？ LINUX的内核是非抢占式的
那么在其内核态下运行的程序不会被调度
但是如果内核态程序自己调用schedule()的话 会出现什么情况(如果不行 内核进程通过什么方法自愿交出CPU使用权）
还有，非抢占是不是通过关中断来实现的。 如果是的话，那时钟中断怎么进行。
而且，如果某个内核态程序出现了诸如死循环的问题 是不是也就没有办法通过其他的方法进行补救了呢？
这个观念是错误的，老早就有人写了可抢占的补丁了。
内核的配置中有个CONFIG_PREEMPT的选项来选择编译成抢占还是非抢占式的内核的。
建议看看spinlock的实现
页:
[1]