弱弱的问问内核中读写锁的问题。

goooogo

内核中的读写锁，可以达到同步读写同一个数据区的问题。
但是，根据个人的理解，读写锁是否有如下的问题：
rwlock_t的lock域被初始化为0x0010_0000，在读的时候，可以对该值进行递减，而在写的时候，要把该值减去0x0010_0000，如果为0，则表示没有任何的读者了，如果有的话，就要进行等待；
而读者在进行获取读锁的时候，可以直接对lock域减1操作，这样就可以直接获取读锁了。
而写者必须要等待所有的读者都操作完成后，才能够获取写锁。

所以，这里边是不是体现出来读者优先，而写者则要等所有读者完成后，才能够获取写锁啊？

另外，读写锁中的break_lock域还没有看出来怎么使用的？

goooogo

请高手指点啊。

自己顶一下。

albcamus

> 所以，这里边是不是体现出来读者优先，而写者则要等所有读者完成后，才能够获取写锁啊？

是的。 其实确切的说，也不见得是读优先，因为只要有一个writer，那么其他所有的read、write申请锁都会自旋。

rwlock的设计就是为了这样的场合： 读很频繁，写很少。

goooogo

>>>是的。 其实确切的说，也不见得是读优先，因为只要有一个writer，那么其他所有的read、write申请锁都会自旋。

这里边是不是存在这样的情况：读者a申请到了读锁，写者b因为发现读者a正在进行读操作，那么那就在自旋；而此时读者c也要申请读锁，此时由于读者c不需要等待a释放锁，就可以申请到读锁，所以，它可以申请到读锁；

那么假如后边有多个读者的情况下，它们都可以申请到读锁，而写者b此时就申请不到写锁，一直处于自旋等待的状态啊？

flw2

原帖由 goooogo 于 2009-6-26 18:09 发表
>>>是的。 其实确切的说，也不见得是读优先，因为只要有一个writer，那么其他所有的read、write申请锁都会自旋。

这里边是不是存在这样的情况：读者a申请到了读锁，写者b因为发现读者a正在进行读操作，那么那 ...

基本上是这样。但是也不是绝对

假设已经有一个读者得到读锁，那么写锁肯定是获得不到的，但是写者还会自旋， 这段代码理论上有可能导致其它读者也得不到读锁，而是随着第一个读者的释放而抢到写锁。

hb12112

我也有这样的疑问,内核有没有对读写锁的申请顺序做维护?

xiegang112

恩，这样避免了写饥饿

epegasus

原帖由 hb12112 于 2009-6-29 15:22 发表
我也有这样的疑问,内核有没有对读写锁的申请顺序做维护?

想到一块了,我觉得不需要维护一个链表一样的锁顺序,而只要实现一个类似双锁的结构即可.

goooogo

其实，我的问题描述的是这样子：
在写者自旋等待获取锁的时候，在写者之后申请读锁的读者，会不会申请到呢？

我的理解是可以申请到的。
而你的解释感觉是申请不到的。

snoopy3810

原帖由 goooogo 于 2009-7-1 14:47 发表
其实，我的问题描述的是这样子：
在写者自旋等待获取锁的时候，在写者之后申请读锁的读者，会不会申请到呢？

我的理解是可以申请到的。
而你的解释感觉是申请不到的。

如果按你最先的描述，岂不是写者要死锁了。。。。。。