用户空间的读写锁的实现已经有很多了，评价一个实现的好坏的标准也不一样，本文的实现是一个抄袭，也可以说是一个改进，抄袭谁的呢？当然是我最熟悉的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内核的实现的作者就是我自己。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1274104
