Tmobile家的30 Monthly 4G Plan可以用在Ipad上 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Apple - 家有苹果

Tmobile家的30 Monthly 4G Plan可以用在Ipad上

Tmobile家的30 Monthly 4G Plan可以用在Ipad上# Apple - 家有苹果

r*o2012-10-09 07:10

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。所以很迷惑。
不知道我的问题说清楚没有。请大牛指教。

j*12012-10-09 07:10

2 楼

按照藏传佛教的传统，怎样学习一部论典才能真正领会其中的意义？
答：首先，要背诵它的颂词；第二，要知道这部论的科判是怎么立的，整部论的科判在
你的心中清清楚楚；第三，不看讲义也能解释颂词的字面意思；第四，对每一品所宣讲
的内容或者颂词的大概意思进行研讨分析，不仅要在字面上通达，还要总结它的要义，
对每个比较重要的问题破析研究。如果你没有这样，光从字面上简单滑过去，这不叫学
习论典，只不过在听传承而已。

A*n2012-10-09 07:10

3 楼

刚刚把Tmobile的卡放在Ipad里，显示有信号，不过是Edge网络。不过看普通网页（比
如新浪，mitbbs之类的）还是挺快的。哈哈，要是以后tmobile 3g refram成功后，用T
家的30 Monthly 4g plan,那且不是多了件上网的利器？
唯一问题就是，卡换来换去的比较麻烦。。

l*y2012-10-09 07:10

4 楼

为啥没有别的进程获得CPU？只要别的进程priority比A高，就可以preempt A吧，还有A
的时间片用完了，就自动让出CPU了吧。
还有我没看到过说uniprocessor上不能用spin_lock

d*d2012-10-09 07:10

5 楼

随喜分享！

r*o2012-10-09 07:10

6 楼

我也这么觉得。
你能不能看看这篇文章，好像还涉及到什么抢占的问题。
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*y2012-10-09 07:10

7 楼

我的理解是，当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*k2012-10-09 07:10

8 楼

That's correct.
on UP without preemption, spinlock is no-op.

r*o2012-10-09 07:10

9 楼

多谢。
请问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*n2012-10-09 07:10

10 楼

spinlock是busy waiting。在multiprocessor的情况下才比较有用（减少context
switch产生的cost等），uniprocessor下比较浪费cpu，要在调度（被动）后才能让出
cpu，效果不如一般的lock。

【在 r****o 的大作中提到】

: 多谢。
: 请问A进程spin_lock()的过程中，time slice还有效吗? A会不会独占CPU，一直到获得
: lock为止？
:
: ()
: spin_

K*g2012-10-09 07:10

11 楼

不是这样的吧？
据我的理解，如果另一个hold lock的进程如果时间比较长的话，spinlock在UniProc上
会增加scheduler的负担，大量的时间消耗在swap上，导致hold lock的那个进程的进展
很慢，结果系统的performance降低了。如果在MultiProc上,hold lock的那个进程不会
因为spinlock而减慢,这样子spinlock的影响就没有UniProc上那么大了.
如果spinlock真的要disable preemption的话，那么它只能出现在MultiProc上。但是，spinlock的概念在UniProc上也存在。

()
spin_

【在 l*******y 的大作中提到】

r*o2012-10-09 07:10

12 楼

就是说uniprocessor下某个进程spin_lock()还是不能一直独占CPU的，时间片到了还是
得让出，对吗?

【在 b*********n 的大作中提到】

: spinlock是busy waiting。在multiprocessor的情况下才比较有用（减少context
: switch产生的cost等），uniprocessor下比较浪费cpu，要在调度（被动）后才能让出
: cpu，效果不如一般的lock。

l*y2012-10-09 07:10

13 楼

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*y2012-10-09 07:10

14 楼

请再去看看书，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*o2012-10-09 07:10

15 楼

非常感谢，请看看我的理解对不对。
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*y2012-10-09 07:10

16 楼

在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*k2012-10-09 07:10

17 楼

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*o2012-10-09 07:10

18 楼

非常感谢。
再问一下，是不是目前的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*k2012-10-09 07:10

19 楼

yes, linux kernel2.6 has kernel preemption support.