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.

The TLightweightMREWEx record implements the same public functions as TLightweightMREW. Functions from the xxxRead family are simply forwarded to internal FRWLock: TLightweightMREW while the xxxWrite family of functions is reimplemented inside the new record:

type
  TLightweightMREWEx = record
  private
    FRWLock: TLightweightMREW;
    [volatile] FLockOwner: TThreadID;
    FLockCount: integer;
  public
    class operator Initialize(out Dest: TLightweightMREWEx);
    procedure BeginRead; inline;
    function TryBeginRead: Boolean; {$IF defined(LINUX) or defined(ANDROID)}overload;{$ENDIF} inline;
    {$IF defined(LINUX) or defined(ANDROID)}
    function TryBeginRead(Timeout: Cardinal): Boolean; overload; inline;
    {$ENDIF LINUX or ANDROID}
    procedure EndRead; inline;
    procedure BeginWrite;
    function TryBeginWrite: Boolean; {$IF defined(LINUX) or defined(ANDROID)}overload;
    function TryBeginWrite(Timeout: Cardinal): Boolean; overload;
    {$ENDIF LINUX or ANDROID}
    procedure EndWrite;
  end;

class operator TLightweightMREWEx.Initialize(out Dest: TLightweightMREWEx);
begin
  Dest.FLockOwner := 0;
end;

To understand the introduced logic, let's examine the new BeginWrite method:

procedure TLightweightMREWEx.BeginWrite;
begin
  if FLockOwner = TThread.Current.ThreadID then
    Inc(FLockCount)
  else begin
    FRWLock.BeginWrite;
    FLockOwner := TThread.Current.ThreadID;
    FLockCount := 1;
  end;
end;

When a record is not locked for writing, FLockOwner is zeroed out. When BeginWrite is called, first test fails and the else branch calls BeginWrite. When it returns, we can be sure that the write lock was granted. The code can now safely modify (as not other thread could have passed BeginWrite) the FLockOwner and FLockCount fields to mark that the current threads owns the lock.

If two threads call BeginWrite at the same time, only one will win while another will block so that also doesn't represent a problem.

If the first thread (the one owning the lock) calls BeginWrite again, the first if condition will be True and the code will simply increment the lock count. This can again only happen in one thread (the one owning the lock) so we can safely increment the lock count.

The EndWrite call does the same in reverse:

procedure TLightweightMREWEx.EndWrite;
begin
  if FLockOwner <> TThread.Current.ThreadID then
    raise Exception.Create('Not an owner');

  Dec(FLockCount);
  if FLockCount = 0 then begin
    FLockOwner := 0;
    FRWLock.EndWrite;
  end;
end;

A safety check at the beginning verifies that EndWrite was indeed called from the thread that owns the lock. After that the lock count is decremented and if the new lock count is 0, FLockOwner is cleared and the lock is released. As all the code up to the final line (the call to FRWLock.EndWrite) can only execute from one thread at a time, all variable manipulations are safe.

The two TryBeginWrite functions are implemented almost the same as BeginWrite except that we have to take care of managing the function result:

function TLightweightMREWEx.TryBeginWrite: Boolean;
begin
  if FLockOwner = TThread.Current.ThreadID then begin
    Inc(FLockCount);
    Result := true;
  end
  else begin
    Result := FRWLock.TryBeginWrite;
    if Result then begin
      FLockOwner := TThread.Current.ThreadID;
      FLockCount := 1;
    end;
  end;
end;

Tests

The testing code in rwReentrantWriter runs four simple and fast tests followed by two 10-second stress tests. If everything is OK, the program writes out OK and waits for Enter to be pressed.

Both stress tests constantly try to access write lock from ten threads. At the end of the test the code logs the number of acquired write locks for each thread. If everything is working correctly, we would expect about the same number of locks acquired in each thread.

For example, on my Windows notebook the test logs:

.....

47358 48721 45511 46172 46296 51432 47468 48406 48987 48025

46470 46667 46641 46801 47584 46641 46110 47101 46892 47417

OK

On Ubuntu 18.04 running under the WSL subsystem on the same machine the numbers are lower, but still quite balanced:

.....

10289 9195 8792 9629 8816 11759 7611 9334 7284 9163

8478 8595 9077 9948 9627 8729 8259 8282 11158 9247

OK