Unreliable Guide to Locking -by Rusty Russell-中文版

albcamus

原帖由 zalem 于 2005-12-23 10:38 发表
呵呵，老早就拜读过了，不过只看了描述部分,涉及到linux的实现就全部略过了，以后再慢慢看...锁真让人头痛...搞通了的人，都是机器人...

会用就行了，spin_lock的实现，记得《情景分析》上有想当详细的讲解，偶还读过呢：）

zalem

...老大的《bsd内核设计与实践》多久看完的？
准备两个一起搞了，本来是说拿bsd做铺垫的...

albcamus

我没看BSD啊，那本4.4.BSD的书，我手头有，但是不看，你要的话可以寄过去，放我手里浪费了

zalem

呵呵，谢谢了，我买了本同系列的新版讲《freebsd》的，不过它实在是非英文的讨论和资料都太少了。本来说拿bsd的些基础做linux的预备知识的...

不好意思，发现和主题无关了...不水了...

1jjk

斑竹看看bsd源代码！
可能会有更好的发现呢？！
你说的那本书是不是全是理论，很少用代码实现的？
我去海图时看到4.4bsd设计原理实践了

1jjk

这个主要是讲互斥，我们课上老师也讲过了！
很生动！呵呵

jeffshia

albcamus 老兄的译作，钦佩！

guotie

7.2.1. 对死锁的防备过当


死锁诚然会带来问题，然而不如数据腐败(data corruption)之甚。试想这样的一段代码，它获取一把读锁，搜索一个链表，如果没找到想要的数据，就释放掉读锁，然后获取一把写锁，把对象插入到链表：这样的代码存在竞态问题。

如果你看不出为什么，那就请离我的代码他妈的远点儿。



不好意思，我悟性低，不明白为什么，能解释下么？

albcamus

举个例子来说：

在CPU1上，和CPU2上，两段代码都试图获取同一把锁，CPU1先成功了，这时候CPU2在自旋，我们看看可能发生什么：

1. ==》CPU1获取一把读锁，搜索一个链表，如果没找到想要的数据，//此时CPU2一直在自旋

2, ==》 CPU1就释放掉读锁， //此时CPU2好不容易等到加锁成功了

3, ==》 CPU1然后获取一把写锁，把对象插入到链表 //由于上一步CPU2加锁成功，它可能进行了写操作，改变了原来的数据， 等到CPU1再获取写锁成功， 早就不是它原来判断的情况了。


LDK说，如果你觉得某段代码中，你想先用读锁再用写锁，或者先用写锁再用读锁， 那么，你最好只用普通的自旋锁。

guotie

感谢！！！