"Go" "Thread" ReaderWriterLock read-write lock

ReaderWriterLock Class

Typically, an instance of a type is thread-safe for parallel reads, but parallel root operations are not (both read and update in parallel). This is the same for resources, such as a file. When an instance of a protected type is secure, using a simple exclusive lock solves the problem, but when there are a lot of read operations and occasional update operations, it is unreasonable to limit concurrency. An example is this in a business program server, in order to quickly find the data cached into a static field. In this scenario, the ReaderWriterLock class is designed to provide a maximum capacity lock.

ReaderWriterLock provides different methods for reading and writing locks--acquirereaderlock and AcquireWriterLock. Two methods require a timeout parameter and throw a ApplicationException exception after the time-out (different from the return false equivalent of most thread classes). Timeouts occur fairly easily when resource contention is severe.

Call Releasereaderlock or Releasewriterlock to release the lock. These methods support nested locks, and the ReleaseLock method also supports clearing all nested levels of locks at once. (You can then call the RestoreLock class to re-lock the same level, which is executed before releaselock-so that it mimics the monitor.wait lock-toggle behavior).

You can call AcquireReaderLock to start a read-lock and then upgrade it to Write-lock through UpgradeToWriterLock. This method returns a message that may be used to invoke Downgradefromwriterlock. This method allows the read program to temporarily request write access without having to re-queue the column after demotion.

In the following example, 4 threads are started: one keeps adding items to the list, the other keeps removing items from the list, and the other two keeps reporting the number of items in the list. The first two get the lock written, after both get read the lock. The timeout parameter for each lock is 10 seconds. (Exception handling is typically used to capture ApplicationException, which is omitted for convenience).

Example:

classProgram {StaticReaderWriterLock RW =NewReaderWriterLock (); StaticList <int> items =NewList <int> (); StaticRandom Rand =NewRandom (); Static voidMain (string[] args) {        NewThread (Delegate() { while(true) Appenditem (); } ).        Start (); NewThread (Delegate() { while(true) RemoveItem (); } ).        Start (); NewThread (Delegate() { while(true) writetotal (); } ).        Start (); NewThread (Delegate() { while(true) writetotal (); } ).     Start (); }      Static intGetrandnum (intmax) { Lock(RAND)returnRand. Next (max); }      Static voidwritetotal () {rw. AcquireReaderLock (10000); inttot =0;foreach(intIinchItems) Tot + =i;        Console.WriteLine (TOT); rw.     Releasereaderlock (); }      Static voidAppenditem () {rw. AcquireWriterLock (10000); Items. ADD (Getrandnum ( +)); Thread.spinwait ( -); rw.      Releasewriterlock (); }      Static voidRemoveItem () {rw. AcquireWriterLock (10000); if(Items. Count >0) items. RemoveAt (Getrandnum (items.        Count)); rw.     Releasewriterlock (); }}        

Adding a project to a list is faster than removing it, and this example includes spinwait in Appenditem to keep the total number of items balanced.

In the order in which the requests arrive, there are four types:
Reader-reader, the second one does not need to wait, direct access to read control rights;
Reader-writer, the second one needs to wait for the first call Releasereaderlock () to release the read control before the write control is obtained;
Writer-writer, the second needs to wait for the first call Releasewriterlock () to release write control before the write control is obtained;
Writer-reader, the second needs to wait for the first call Releasewriterlock () to release write control before it can gain read control.

Original link: http://www.cnblogs.com/coderzh/articles/1586268.html

"Go" "Thread" ReaderWriterLock read-write lock