Subj : Re: Improving read-write lock
To   : comp.programming.threads
From : Joe Seigh
Date : Wed Feb 16 2005 11:44 am

On Wed, 16 Feb 2005 15:50:05 +0100, Rob <rob@nowhere.xyz> wrote:

>
> An idea my colleague has was to introduce a new kind of lock type:
> ReadPromotable.

Promotable locks are not new.  They even use that same term.

> The new lock could give 3 kind of locks:
> - Read: for only reading. You would take this lock if you are sure you
> only need to read.
>    Multiple read-locks can exist as usual.
> - Write: for reading and writing. You would take this lock if you are
> sure you will need
>    to do a lot of writing. Only one write-lock can exist, without any
> concurrent read-locks.
> - ReadPromotable: for reading and possibility to upgrade to a write
> lock. You would
>    take this lock in the doStuff() function above, because you need to
> read, but
>    maybe need to write to without letting someone modify the object first.
>    Only one ReadPromotable lock can exist, however multiple read-locks
> can exist at
>    the same time as the ReadPromotable lock.>
> When the ReadPromotable lock is being upgraded to a write lock, it has
> to wait for any
> read-locks to finish.
>
> It's not a perfect situation of course, because only one ReadPromotable
> lock exists.

More than one promotable read lock can exist.  It just has to stay blocked
until any pior promotable read locks have completed their write access. So
it sort of looks like a write lock request at that point.

> However I hope you can see the improved concurrency compared to a normal
> read-write lock.
>

You'll get improvement if the read phase of a read-modify-write takes a
relatively long time.

The other way this has been done is to just have regular read and write locks
and make the upgrade from read access to write access conditional.  Programs
that use this interface have to check the return code of course.


-- 
Joe Seigh

Lock-free synchronization primitives
http://atomic-ptr-plus.sourceforge.net/

.