用户空间读写锁的实现

用户空间的读写锁的实现已经有很多了，评价一个实现的好坏的标准也不一样，本文的实现是一个抄袭，也可以说是一个改进，抄袭谁的呢？当然是我最熟悉的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内核的实现的作者就是我自己。