讀 寫鎖的實現和應用（高併發狀態下的map實現）

程式中涉及到對一些共享資源的讀和寫操作，且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候，兩個執行緒同時讀乙個資源沒有任何問題，所以應該允許多個執行緒能在同時讀取共享資源。但是如果有乙個執行緒想去寫這些共享資源，就不應該再有其它執行緒對該資源進行讀或寫（譯者注：也就是說：讀-讀能共存，讀-寫不能共存，寫-寫不能共存）。這就需要乙個讀/寫鎖來解決這個問題。

按照上面的敘述，簡單的實現出乙個讀/寫鎖

public

class
readwritelock
readers++;
}  public synchronized void
unlockread()
public synchronized void
lockwrite()
throws interruptedexception
writerequests--;
writers++;
}  public synchronized void
unlockwrite()
throws interruptedexception
}

readwritelock類中，讀鎖和寫鎖各有乙個獲取鎖和釋放鎖的方法。

可重入的readwritelock的完整實現

下面是完整的readwritelock實現。為了便於**的閱讀與理解，簡單對上面的**做了重構。重構後的**如下。

public

class
readwritelock
readingthreads.put(callingthread,
(getreadaccesscount(callingthread) + 1
)); }
private
boolean cangrantreadaccess(thread callingthread)
public synchronized void
unlockread()
int accesscount =getreadaccesscount(callingthread);
if(accesscount == 1
) else
notifyall(); } 
public synchronized void
lockwrite()
throws interruptedexception
writerequests--;
writeaccesses++;
writingthread =callingthread; } 
public synchronized void
unlockwrite()
throws interruptedexception
writeaccesses--;
if(writeaccesses == 0
)     notifyall(); } 
private
boolean cangrantwriteaccess(thread callingthread)
private
intgetreadaccesscount(thread callingthread)
private
boolean hasreaders()
private
boolean isreader(thread callingthread)
private
boolean isonlyreader(thread callingthread)
private
boolean haswriter()
private
boolean iswriter(thread callingthread)
private
boolean haswriterequests()
}

應用：執行緒安全並且高併發狀態下的map實現

class

rwdictionary 
finally
}public
string allkeys() 
finally
}public
data put(string key, data value) 
finally
}public
void
clear() 
finally
}}

讀 寫鎖的實現和應用（高併發狀態下的map實現）

程式中涉及到對一些共享資源的讀和寫操作，且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候，兩個執行緒同時讀乙個資源沒有任何問題，所以應該允許多個執行緒能在同時讀取共享資源。但是如果有乙個執行緒想去寫這些共享資源，就不應該再有其它執行緒對該資源進行讀或寫 譯者注 也就是說 讀 讀能共存，讀 寫不能共存，...

php高併發狀態下檔案的讀寫

背景 1 對於pv不高或者說併發數不是很大的應用，不用考慮這些，一般的檔案操作方法完全沒有問題 2 如果併發高，在我們對檔案進行讀寫操作時，很有可能多個程序對進一檔案進行操作，如果這時不對檔案的訪問進行相應的獨佔，就容易造成資料丟失 對於這樣的問題，一般的解決方案 1 當一程序對檔案進行操作時，首先...

binlog在併發狀態下的記錄

前兩天看binlog發現個奇怪的地方 對於position靠後的記錄，timestamp卻比之前的記錄還要小。當時覺得大概和併發有關係 後來做了個實驗 開兩個session 對於session1 begin insert into t1 values 1 insert into t1 values ...