读写模型
读写模型是一个稍微复杂一些的模型。
一份共享资源允许多个读者同时读取。但是只要有一个写者在写这份共享资源,任何其他的读者和写者都不能访问这份共享资源。
读写模型实现起来,不仅需要信号量机制,还需要额外的读者计数和写者计数。
public static final Object signal = new Object();
public static int readers = 0;
public static int writers = 0;
// 读者代码
… read() {
for(… ) { // 循环执行
synchronized(signal){
while( writers > 0 )
signal.wait(); // 如果有人在写,那么就放弃执行,进入待召队列
// 能够到达这里,说明没有人在写
readers ++ ; // 增加一个读者计数,表示本线程在读取
} // 这里出了synchronized范围,释放同步锁.以便其他线程读取.
// 进行一些读取操作
synchronized(signal){
readers --; // 读取完成,减少一个读者计数,表示本线程不在读取
signal.notifyAll(); // 通知待召队列里面的所有其他线程
}
}
}
// 写者代码
… write() {
for(… ) { // 循环执行
synchronized(signal){
while( writers > 0 || readers > 0)
signal.wait();// 如果有人在写或读,那么就放弃执行,进入待召队列
// 能够到达这里,说明没有人在写,也没有人在读
writers ++ ; // 增加一个写者计数,表示本线程在写
// 进行一些写操作
writers --; // 读取完成,减少一个读者计数,表示本线程不在写
signal.notifyAll(); // 通知待召队列里面的所有其他线程
}
}
}
读写模型是一个稍微复杂一些的模型。
一份共享资源允许多个读者同时读取。但是只要有一个写者在写这份共享资源,任何其他的读者和写者都不能访问这份共享资源。
读写模型实现起来,不仅需要信号量机制,还需要额外的读者计数和写者计数。
public static final Object signal = new Object();
public static int readers = 0;
public static int writers = 0;
// 读者代码
… read() {
for(… ) { // 循环执行
synchronized(signal){
while( writers > 0 )
signal.wait(); // 如果有人在写,那么就放弃执行,进入待召队列
// 能够到达这里,说明没有人在写
readers ++ ; // 增加一个读者计数,表示本线程在读取
} // 这里出了synchronized范围,释放同步锁.以便其他线程读取.
// 进行一些读取操作
synchronized(signal){
readers --; // 读取完成,减少一个读者计数,表示本线程不在读取
signal.notifyAll(); // 通知待召队列里面的所有其他线程
}
}
}
// 写者代码
… write() {
for(… ) { // 循环执行
synchronized(signal){
while( writers > 0 || readers > 0)
signal.wait();// 如果有人在写或读,那么就放弃执行,进入待召队列
// 能够到达这里,说明没有人在写,也没有人在读
writers ++ ; // 增加一个写者计数,表示本线程在写
// 进行一些写操作
writers --; // 读取完成,减少一个读者计数,表示本线程不在写
signal.notifyAll(); // 通知待召队列里面的所有其他线程
}
}
}
上述代码只是一段示意代码。实际应用中,人们通常抽取出来一个专门的读写同步锁。
interface ReadWriteLock {
… getReadLock();
… releaseReadLock();
… getWriteLock();
… releaseWriteLock();
}
具体的实现原理也是类似的信号量同步机制。
class RWLock {
… readers, writers;
… synchronized … getReadLock() { // 相当于synchronized(this)
…
while( writers > 0 )
this.wait(); // 这里我们把RWLock对象本身作为信号量
readers++;
}
…synchronized … releaseReadLock(){ //相当于synchronized(this)
readers--;
this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量
}
…synchronized … getWriteLock(){// 相当于synchronized(this)
while( writers > 0 || readers > 0 )
this.wait(); // 这里我们把RWLock对象本身作为信号量
writers++;
}
…synchronized … releaseWriteLock(){// 相当于synchronized(this)
writers--;
this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量
}
}
具体用法是
public static final RWLock lock = new RWLock();
… read() {
lock.getReadLock();
// 读取
lock.releaseReadLock();
}
… write() {
lock.getWriteLock();
// 读取
lock.releaseWriteLock();
}
interface ReadWriteLock {
… getReadLock();
… releaseReadLock();
… getWriteLock();
… releaseWriteLock();
}
具体的实现原理也是类似的信号量同步机制。
class RWLock {
… readers, writers;
… synchronized … getReadLock() { // 相当于synchronized(this)
…
while( writers > 0 )
this.wait(); // 这里我们把RWLock对象本身作为信号量
readers++;
}
…synchronized … releaseReadLock(){ //相当于synchronized(this)
readers--;
this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量
}
…synchronized … getWriteLock(){// 相当于synchronized(this)
while( writers > 0 || readers > 0 )
this.wait(); // 这里我们把RWLock对象本身作为信号量
writers++;
}
…synchronized … releaseWriteLock(){// 相当于synchronized(this)
writers--;
this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量
}
}
具体用法是
public static final RWLock lock = new RWLock();
… read() {
lock.getReadLock();
// 读取
lock.releaseReadLock();
}
… write() {
lock.getWriteLock();
// 读取
lock.releaseWriteLock();
}
这种用法要求在执行一些处理之前,一定要执行某项特殊操作,处理之后一定也要执行某项特殊操作。这种人为的顺序性,无疑增加了代码的耦合度,降低了代码的独立性。很有可能会成为线程死锁和资源操作冲突的根源。
这点一直让我不安,可是没有找到方法避免。毕竟,死锁或者资源操作冲突,是线程的固有问题。
很巧的是,正在我惴惴不安的时候,我的一个朋友提供了一个信息。Sun公司根据JCR,决定在jdk1.5中引入关于concurrency(并发)的部分。
以下这个网址是concurrency部分的util.concurrent一个实现。非常好的信息。对于处理多线程并发问题,很有帮助。
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
里面提供了一个ReadWriteLock类,标准用法如下。
Standard usage of ReadWriteLock:
class X {
ReadWriteLock rw;
// ...
public void read() throws InterruptedException {
rw.readLock().acquire();
try {
// ... do the read
}
finally {
rw.readlock().release()
}
}
public void write() throws InterruptedException {
rw.writeLock().acquire();
try {
// ... do the write
}
finally {
rw.writelock().release()
}
}
}
我们可以看到,ReadWriteLock同样要求调用的顺序——aquire()和release()。我对自己的例子增强了一点信心。
我又查看了WriterPreferenceReadWriteLock类,看到里面成对的方法,startRead(),endRead();startWrite(),endWrite()。我的心情完全放松了下来。我的思路虽然粗糙,但大体的方向是正确的
这点一直让我不安,可是没有找到方法避免。毕竟,死锁或者资源操作冲突,是线程的固有问题。
很巧的是,正在我惴惴不安的时候,我的一个朋友提供了一个信息。Sun公司根据JCR,决定在jdk1.5中引入关于concurrency(并发)的部分。
以下这个网址是concurrency部分的util.concurrent一个实现。非常好的信息。对于处理多线程并发问题,很有帮助。
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
里面提供了一个ReadWriteLock类,标准用法如下。
Standard usage of ReadWriteLock:
class X {
ReadWriteLock rw;
// ...
public void read() throws InterruptedException {
rw.readLock().acquire();
try {
// ... do the read
}
finally {
rw.readlock().release()
}
}
public void write() throws InterruptedException {
rw.writeLock().acquire();
try {
// ... do the write
}
finally {
rw.writelock().release()
}
}
}
我们可以看到,ReadWriteLock同样要求调用的顺序——aquire()和release()。我对自己的例子增强了一点信心。
我又查看了WriterPreferenceReadWriteLock类,看到里面成对的方法,startRead(),endRead();startWrite(),endWrite()。我的心情完全放松了下来。我的思路虽然粗糙,但大体的方向是正确的