Low-Lock Techniques in action: Implementing a Reader-Writer lock

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

Peter Ritchie — Tue, 28 Mar 2006 20:21:16 GMT

Vance, in your ReaderWriterLock sample use, is your comment "// No readers or other writers can be in here." suggestiong that another myLock.AcquireWriterLock(...) call would block?

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

Peter Ritchie — Tue, 28 Mar 2006 20:47:05 GMT

Vance, are you suggesting by the comment "// No readers or other writers can be in here." in the ReaderWriterLock sample use that adding another call to myLock.AcquireWriterLock(...) before myLock.ReleaseWriterLock() would block or throw an exception?

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

vancem — Tue, 28 Mar 2006 21:30:19 GMT

Peter:

The // No readers or other writers can be in here comment does mean you indicate, that a call to myLock.AquireWriterLock or myLock.AquireReaderLock will block (wait), until the lock is released.

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

Peter Ritchie — Tue, 28 Mar 2006 21:55:44 GMT

Vance, the documentation for ReaderWriterLock.AcquireWriterLock states: "AcquireWriterLock supports recursive writer-lock requests. That is, a thread can call AcquireWriterLock multiple times, which increments the lock count each time. ... Recursive lock requests are always granted immediately, without placing the requesting thread in the writer queue." So, adding another myLockAcquireWriter(...) before myLock.ReleaseWriterLock() will never block. Your new comment should say AcquireReaderLock() blocks not Acquire*Lock() blocks.

Of course, that presupposes a matching ReleaseWriterLock() is added to any additional AcquireWriterLock()...

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

Peter Ritchie — Tue, 28 Mar 2006 21:59:36 GMT

A quick test of:

MyReaderWriterLock myLock = new MyReaderWriterLock();

myLock.AcquireWriterLock(Timeout.Infinite);
myLock.AcquireWriterLock(Timeout.Infinite);
myLock.ReleaseWriterLock();
myLock.ReleaseWriterLock();

confirms this.

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

vancem — Tue, 28 Mar 2006 23:48:11 GMT

Peter:

Yes, you are correct that the current implementation of MyReaderWriterLock is NOT recurisve (reentrant). This was last of the additions that I suggested was straightfoward to add. You are correct that it is not a truely drop-in replacement without it (but it is also not a drop-in replacement unless I implement all the other little-used APIs like lock upgrade).

If you are interesting in seeing the reentrant version, I just say so and I can blog about that next.

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

Peter Ritchie — Wed, 29 Mar 2006 00:16:48 GMT

Sorry, my code sample should have used ReaderWriterLock, not MyReaderWriterLock.

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

snaveen — Wed, 29 Mar 2006 04:51:49 GMT

Other problems with ReaderWriterLock is that the reads have higher priority than the writes which I think shouldn’t. If there are few readers locking an object and a writer wants to write then writer should be given higher priority which I think is not that is happening in BCL ReadWriterLock due to this there is a starvation. This is one of the reason few of them aren’t using readerwriter lock other than the performance issue that you have mentioned.

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

onovotny — Wed, 29 Mar 2006 06:50:42 GMT

It would be very nice if the reader writer lock could be finished up to be a nearly-complete replacement for the built-in version. Perhaps it can live on a GotDotNet workspace?

Thanks!
--Oren

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

zahical — Wed, 29 Mar 2006 12:13:46 GMT

Thanks for the very interesting post. There aren’t many sources on the net about low-lock techniques, so anything about them is welcome.
Please, write more about it – though using low-lock techniques is not something that one happens to do everyday, for me, they are a very good way to learn some funny and obscure facts about the processor, the compiler and the .NET platform.
For me, personally, it will be very interesting (and educating) to see all the versions of the ReaderWriterLock that you mentioned – the one that is reentrant and the one that is fair about the waiters – alongside your comments what differences (behavioral and performance) the changes in the implementation bring.

Interesting Finds

Jason Haley — Wed, 29 Mar 2006 13:14:21 GMT

re: Low-Lock Techniques in action: Implementing a Reader-Writer lock

vancem — Wed, 29 Mar 2006 19:59:39 GMT

In reply to snaveen's comment.

In my experimentation I have personally confirmed that both System.Threading.ReaderWriterLock as well as the MyReaderWriteLock implementation will NOT starve writers. If a writer is waiting for the lock, readers start to block also (They are logically 'behind' the writer in the queue), an so the writer gets the lock as soon as it can (when all the readers that currently hold the lock drain).

I am interested in any reasons why people don't use System.ThreadingReaderWriterLock. Performance may be one of them (however, for other reasons it good to work in big enough chunks that lock performance is not an issue).

Analysis of Reader-Writer lock

Vance Morrison's Weblog — Thu, 30 Mar 2006 17:40:35 GMT

In my last post I posted readerWriterDemo.cs&nbsp;which is an implementation of a Reader-Writer lock.&nbsp;&nbsp;...

Vance on reader-writer locks

Generalities & Details: Adventures in the High-tech Underbelly — Thu, 30 Mar 2006 22:08:02 GMT

Using ReaderWriterLocks part 3 (last in this set)

Rico Mariani's Performance Tidbits — Tue, 16 May 2006 03:33:01 GMT

Well I think it's raining ReaderWriterLocks this month!&nbsp; Jeff Richter has an article on MSDN that...

Locking code

IWebThereforeIAm — Sat, 11 Oct 2008 20:16:15 GMT

Locking code Monitor.TryEnter, lock, using, and Deadlock Jeffrey Richter has an article on why the ReaderWriterLock isn't the best option: Low-Lock Techniques in action: Implementing a Reader-Writer lock Analysis of Reader-Writer lock...

How to manage Control States in Silverlight Applications « All about nothing

Sat, 13 Jun 2009 12:25:47 GMT

PingBack from http://jachman.wordpress.com/2009/06/13/how-to-manage-control-states-in-silverlight-applications/