r****o
发帖数: 1950 | 1 【 以下文字转载自 InterviewHackers 俱乐部 】
发信人: roufoo (五经勤向窗前读), 信区: InterviewHackers
标 题: 问个OS里面spin lock的问题。
发信站: BBS 未名空间站 (Thu May 20 01:18:51 2010, 美东)
我发现我对OS里面进程的同步和调度的概念很不清楚。
spin lock的机制是一个进程A检测自己能否获得lock，如果不能就一直try，直到获得
lock。我的问题是，在uniprocessor系统里面，CPU的调度是不是只分配一部分时间片
给进程A，同时还运行其他进程B,C,D...? 还是说这个进程A就独霸CPU了?
我看到有的文章说因为在uniprocessor上没有别的进程能够获得CPU来释放lock，所以
不能用spin lock。所以很迷惑。
不知道我的问题说清楚没有。请大牛指教。 |
l*******y
发帖数: 1498 | 2 为啥没有别的进程获得CPU？只要别的进程priority比A高，就可以preempt A吧，还有A
的时间片用完了，就自动让出CPU了吧。
还有我没看到过说uniprocessor上不能用spin_lock |
r****o
发帖数: 1950 | 3 我也这么觉得。
你能不能看看这篇文章，好像还涉及到什么抢占的问题。
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxk&Number=622919&page=119&view=collapsed&sb=5&o=all&fpart=all
有A
【在 l*******y 的大作中提到】
: 为啥没有别的进程获得CPU？只要别的进程priority比A高，就可以preempt A吧，还有A
: 的时间片用完了，就自动让出CPU了吧。
: 还有我没看到过说uniprocessor上不能用spin_lock
|
l*******y
发帖数: 1498 | 4 我的理解是，当spin_lock()后，cpu是disable kernel preemption，当spin_unlock()
后，cpu enable kernel preemption. 所以当A进程spin_lock()后，只有等A的time
slice用完了才会让出CPU。在uniprocessor里，disable kernel preemption和用spin_
lock()效果是一样的，所以它就没用实际的spin_lock()而直接
disable kernel preemption。
这本书我看过，它没有专门说spin_lock()后会disable kernel preemption，只是说在
uniprocessor里会这样。我觉得在multi-processor，spin_lock()也会disable 当前
cpu的 preemption |
a**********k
发帖数: 1953 | 5 That's correct.
on UP without preemption, spinlock is no-op. |
r****o
发帖数: 1950 | 6 多谢。
请问A进程spin_lock()的过程中，time slice还有效吗? A会不会独占CPU，一直到获得
lock为止？
()
spin_
【在 l*******y 的大作中提到】
: 我的理解是，当spin_lock()后，cpu是disable kernel preemption，当spin_unlock()
: 后，cpu enable kernel preemption. 所以当A进程spin_lock()后，只有等A的time
: slice用完了才会让出CPU。在uniprocessor里，disable kernel preemption和用spin_
: lock()效果是一样的，所以它就没用实际的spin_lock()而直接
: disable kernel preemption。
: 这本书我看过，它没有专门说spin_lock()后会disable kernel preemption，只是说在
: uniprocessor里会这样。我觉得在multi-processor，spin_lock()也会disable 当前
: cpu的 preemption
|
b*********n
发帖数: 464 | 7 spinlock是busy waiting。在multiprocessor的情况下才比较有用（减少context
switch产生的cost等），uniprocessor下比较浪费cpu，要在调度（被动）后才能让出
cpu，效果不如一般的lock。
【在 r****o 的大作中提到】
: 多谢。
: 请问A进程spin_lock()的过程中，time slice还有效吗? A会不会独占CPU，一直到获得
: lock为止？
:
: ()
: spin_
|
K******g
发帖数: 1870 | 8 不是这样的吧？
据我的理解，如果另一个hold lock的进程如果时间比较长的话，spinlock在UniProc上
会增加scheduler的负担，大量的时间消耗在swap上，导致hold lock的那个进程的进展
很慢，结果系统的performance降低了。如果在MultiProc上,hold lock的那个进程不会
因为spinlock而减慢,这样子spinlock的影响就没有UniProc上那么大了.
如果spinlock真的要disable preemption的话，那么它只能出现在MultiProc上。但是，spinlock的概念在UniProc上也存在。
()
spin_
【在 l*******y 的大作中提到】
: 我的理解是，当spin_lock()后，cpu是disable kernel preemption，当spin_unlock()
: 后，cpu enable kernel preemption. 所以当A进程spin_lock()后，只有等A的time
: slice用完了才会让出CPU。在uniprocessor里，disable kernel preemption和用spin_
: lock()效果是一样的，所以它就没用实际的spin_lock()而直接
: disable kernel preemption。
: 这本书我看过，它没有专门说spin_lock()后会disable kernel preemption，只是说在
: uniprocessor里会这样。我觉得在multi-processor，spin_lock()也会disable 当前
: cpu的 preemption
|
r****o
发帖数: 1950 | 9 就是说uniprocessor下某个进程spin_lock()还是不能一直独占CPU的，时间片到了还是
得让出，对吗?
【在 b*********n 的大作中提到】
: spinlock是busy waiting。在multiprocessor的情况下才比较有用（减少context
: switch产生的cost等），uniprocessor下比较浪费cpu，要在调度（被动）后才能让出
: cpu，效果不如一般的lock。
|
l*******y
发帖数: 1498 | 10 time slice一直有效吧。在UP里，因为已经disable preemption了，所以A占不了CPU。
在MP里，A会占CPU资源，就跟普通的进程一样。所以说，由于它会在那浪费CPU资源一
直spin等lock，spin_lock()只适合短时间的lock，比如占用lock的时间小于2次
context switch时。否则用mutex更好。还有就是在interrupt里不能context switch，
就只能用spin_lock.
【在 r****o 的大作中提到】
: 多谢。
: 请问A进程spin_lock()的过程中，time slice还有效吗? A会不会独占CPU，一直到获得
: lock为止？
:
: ()
: spin_
|
|
|
l*******y
发帖数: 1498 | 11 请再去看看书，spin_lock就是kernel nonpreemptive的标志
是，spinlock的概念在UniProc上也存在。
【在 K******g 的大作中提到】
: 不是这样的吧？
: 据我的理解，如果另一个hold lock的进程如果时间比较长的话，spinlock在UniProc上
: 会增加scheduler的负担，大量的时间消耗在swap上，导致hold lock的那个进程的进展
: 很慢，结果系统的performance降低了。如果在MultiProc上,hold lock的那个进程不会
: 因为spinlock而减慢,这样子spinlock的影响就没有UniProc上那么大了.
: 如果spinlock真的要disable preemption的话，那么它只能出现在MultiProc上。但是，spinlock的概念在UniProc上也存在。
:
: ()
: spin_
|
r****o
发帖数: 1950 | 12 非常感谢，请看看我的理解对不对。
UP系统里面，进程A启用spin_lock后，会在它所分配的time slice里面一直try，直到
获得lock。在CPU分配的其他time slice里面，拥有这个lock的那个进程会运行直到释
放这个lock.
MP系统里面，进程A启用spin_lock后，会一直霸占它所对应的那个CPU，一直到另一个
CPU上拥有这个lock的进程释放了这个lock为止。
我的问题是:
1)在MP系统里面，进程A不受time slice的约束吗？
2)为啥说spin_lock在MP系统里面更好，我觉得在MP系统里面，进程A浪费的时间更多啊?
先感谢了。
【在 l*******y 的大作中提到】
: time slice一直有效吧。在UP里，因为已经disable preemption了，所以A占不了CPU。
: 在MP里，A会占CPU资源，就跟普通的进程一样。所以说，由于它会在那浪费CPU资源一
: 直spin等lock，spin_lock()只适合短时间的lock，比如占用lock的时间小于2次
: context switch时。否则用mutex更好。还有就是在interrupt里不能context switch，
: 就只能用spin_lock.
|
l*******y
发帖数: 1498 | 13 在UP里，如果一个B进程已经得到了lock, 进程A不会去spin_lock(lock)，因为B进程
spin_lock(lock)时已经disable preemption了，A只有等B运行完了或者等B spin_
unlock(lock)后 enable preemption了才可能去try。
在MP里，A也受time slice的约束，它的time slice完了就不能再spin了。但是一般情
况下，spin_lock用于短时间的lock，所以应该在time slice用完前它就会得到lock。
spin是会浪费CPU资源，所以在UP里就直接disable preemption了。但是在MP里，为了
protection from concurrency，这已经是相对来说low overhead了。你不可能像UP那
样disable 所有cpu的 preemption吧，那样更浪费。
所以spin_lock用于非常短时间的lock，比如时间短于2次process context switch (
mutex的overhead).
啊?
【在 r****o 的大作中提到】
: 非常感谢，请看看我的理解对不对。
: UP系统里面，进程A启用spin_lock后，会在它所分配的time slice里面一直try，直到
: 获得lock。在CPU分配的其他time slice里面，拥有这个lock的那个进程会运行直到释
: 放这个lock.
: MP系统里面，进程A启用spin_lock后，会一直霸占它所对应的那个CPU，一直到另一个
: CPU上拥有这个lock的进程释放了这个lock为止。
: 我的问题是:
: 1)在MP系统里面，进程A不受time slice的约束吗？
: 2)为啥说spin_lock在MP系统里面更好，我觉得在MP系统里面，进程A浪费的时间更多啊?
: 先感谢了。
|
a**********k
发帖数: 1953 | 14 preemption means time slice support.
so
on UP with preemption, spinlock = disabling preemption = no time slice;
on UP without preemption, spinlock = no op;
Hope this helps. |
r****o
发帖数: 1950 | 15 非常感谢。
再问一下，是不是目前的UP系统里面大部分还是with preemption的啊?
【在 a**********k 的大作中提到】
: preemption means time slice support.
: so
: on UP with preemption, spinlock = disabling preemption = no time slice;
: on UP without preemption, spinlock = no op;
: Hope this helps.
|
a**********k
发帖数: 1953 | 16 yes, linux kernel2.6 has kernel preemption support. |
m******t
发帖数: 99 | 17 UP 不会用spin lock的，而不是不能用。 |
