Subj : Re: Improving read-write lock
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Wed Feb 16 2005 04:13 pm

Rob <rob@nowhere.xyz> writes:

> An idea my colleague has was to introduce a new kind of lock type:
> ReadPromotable.
[...]
> I would like to know your thought about this.

I've implemented exactly this in my language Kogut.

Unfortunately its documentation as a whole is incomplete. Here is how
I described this feature:

- New type READ_WRITE_LOCK of locks, created by ReadWriteLock().

  Functions LockRead and LockWrite establish a region where multiple
  readers or a single writer are allowed at a time. Functions
  UnlockRead and UnlockWrite temporarily unlock a lock.

  Function LockReadWillWrite locks a lock for reading, but declares
  that later it will possibly be upgraded to writing. Function
  UnlockReadWillWrite temporarily unlocks it. Only one thread at a
  time can have this kind of lock, to avoid deadlocks. It differs from
  a lock for writing in that it can be shared with regular readers.

  Function ChangeLockToWrite upgrades this kind of lock to writing,
  waiting for regular readers to exit the protected region first, and
  preventing other threads from entering it. It atomically downgrades
  the lock back at the end, without waiting. Function ChangeLockToRead
  does the opposite. The state upgraded to writing is the same as the
  state resulting from LockWrite. Neither upgrading nor downgrading
  allows another writer to intervene.

  This implementation does not keep track of which threads obtained
  which locks for reading, and thus performing UnlockRead by a thread
  which has not locked the lock for reading causes undefined behavior.
  Locking a lock for writing by a thread which already has locked it
  for reading causes a deadlock instead of an exception.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

.