用户空间读写锁的实现

晨曦之光 发布于 2012/04/10 15:04
阅读 360
收藏 1

用户空间的读写锁的实现已经有很多了,评价一个实现的好坏的标准也不一样,本文的实现是一个抄袭,也可以说是一个改进,抄袭谁的呢?当然是我最熟悉的linux内核的了,linux内核的读写锁的实现非常的艺术,都知道读写锁是一种不对称的锁,读和写当然是不对称的,在实现上可以体现为代码上的不对称和数据的不对称,然而这两种不对称却从来没有得到人们的关注,我在一本讲MySQL源代码的书上看到了一段描述,主要是讲为何MySQL不用读写锁而用互斥锁,作者认为是读写锁实现起来太复杂,会多浪费好几个cpu周期,实际上得到的优惠还不足以弥补cpu周期浪费。从这一段描述中可以看得出的是,MySQL的作者将读写锁实现中不对称设想成了代码的不对称,这样才会得到浪费cpu周期的结论,如果考虑数据的不对称,哪个数据对于cpu来讲是无所谓的,只是代码加工的原料而已。linux内核巧妙的使用了数据的不对称性来实现读写锁,这个就自己看代码吧。

近期我在一篇blog上看到了一个读写锁的实现,语言是java,用什么语言似乎不是那么重要,关键是如何实现的,首先看一下这个代码:

public class ReadWriteLock {

private boolean isRead;

private boolean isWrite;

public synchronized void readLock() {

while (isWrite) {

try {

wait();

} catch (InterruptedException ex) {

ex.printStackTrace();

}

}

isRead=true;

}

public synchronized void readUnlock() {

isRead=false;

notifyAll();

}

public synchronized void writeLock() {

while(isRead) {

try {

wait();

} catch(InterruptedException ex) {

ex.printStackTrace();

}

}

while(isWrite) {

try{

wait();

} catch(InterruptedException ex) {

ex.printStackTrace();

}

}

isWrite=true;

}

public synchronized void writeUnlock() {

isWrite=false;

notifyAll();

}

}

看完了给人的感觉就是简单之极,很容易理解,面试的时候肯定能过关,但是明显read和write的lock代码量不同,写锁的代码量几乎是读锁的两倍,如果看了下面的实现,如果下面实现的作者和上面的作者一起参加了一场面试,我估计上面的哥们就危险了,当然同时被录取更好,就怕是二选一的情况。看完上面的实现以后我估计MySQL的作者担心是有道理的,他肯定也把读写锁的实现想成了上面的样子,下面看看仿linux内核的实现:

public class ReadWriteLock {

int count = 200;

int delta = count; //读锁的共享量,当然可以更大些,200000都可以。

public synchronized void readLock() {

doLockUnlock(1, 1);

}

public synchronized void readUnlock() {

doLockUnlock(delta, 0);

}

public synchronized void writeLock() {

doLockUnlock(delta, 1);

}

public synchronized void writeUnlock() {

doLockUnlock(delta, 0);

}

public synchronized void doLockUnlock(int delta, int op) {

if (op) {

while(count-delta <=0) {

try {

wait();

} catch(InterruptedException ex) {

ex.printStackTrace();

}

}

count -= delta;

} else {

count += delta;

notifyAll();

}

}

}

最后说一下,上面的仿linux内核的实现的作者就是我自己。


原文链接:http://blog.csdn.net/dog250/article/details/5302942
加载中
返回顶部
顶部