Readers-writer lock - Part 4: Improving TLightweightMREW

While the TLightweightMREW is quite handy, it is not perfect. There's a weird assymmetry in it. On all operating systems that Delphi can compile for, read locks are reentrant (recursive) while write locks are not. In other words, if a thread already owns a read lock, it can call BeginRead again and it will succeed. Write locks are different. If a thread already owns a write lock and calls BeginWrite again, it will either deadlock (on Windows) or raise an exception (on other supported platforms).

This is, however, relatively simple to fix. I have implemented a simple wrapper for the TLightweightMREW lock in TLightweightMREWEx. This new record uses internal TLightweightMREW to provide locking and adds some simple logic to implement write lock reentrancy. The implementation and accompanying test program rwReentrantWriter can be found at https://github.com/gabr42/examples/tree/master/Reader-writer%20lock.

Readers-writer lock - Part 3: Some numbers

In order to convince you that a readers-writer lock is not a stupid idea, I should finally show some numbers. In this article I'll present a minimalistic (but still real-life) example which allows us to compare different locking solutions.

All code from this article is available in project rwLock at  https://github.com/gabr42/examples/tree/master/Reader-writer%20lock

Readers-writer lock - Part 2: Implementation

In the previous installment I introduced the idea of a readers-writer lock. Today I'll look into readers-writer lock implementations (yes, multiple) that are available in the Delphi run-time library.

Readers-writer lock - Part 1: Why?

One of the pleasant surprises in Delphi 10.4.1 was the addition of a new readers-writer lock implementation TLightweightMREW. While it was probably not noticed by most of the users, I was quite happy to see it implemented. 

So now you are asking yourself - what is this readers-writer lock and why am I so happy to see it in Delphi? Well, I'm glad that you're asking! Let me explain ...

In multithreaded programming (as most of my horror stories start), we frequently run into a problem of resource sharing. Two threads want to modify a shared resource at the same time and that can cause many problems, from information being overwritten to corrupted data and program crashes.

To fix this, we add resource protection. Usually that is just a critical section (typically through a TCriticalSection wrapper), or Delphi's TMonitor. Sometimes, however, protecting resources with a simple critical section causes an unnecessary performance drop, and that's when a readers-writer lock (may) come into play.