[RFC] Allowing write locks with in read locks

[Martin Pool]

hOn 28 June 2010 20:48, Gary van der Merwe <garyvdm at gmail.com> wrote:
> In bzr, commands are generally either a read command, or a write
> command.  But in gui's a one can do a write action from read command
> window. E.g. tag in log, revert in browse.
>
> After encountering Bug #133220 in bzr-gtk, when working on qbzr, I
> took the design approach to hold locks for a short a time as possible:
> e.g. for qlog we:
>
> * take read lock
> * read graph
> * read revision currently on screen
> * unlock
>
> (user scrolls)
> * take read lock
> * read revision currently on screen
> * unlock
>
> Then if the user tries to do a read action, the lock will be able to be taken.
>
> Andrew Bennetts pointed out to me at UDS that this will not result in
> optimal performance. Not only due to the cost of taking the lock, but
> also invalidation of caches.
>
> I feel that a solution where we unlock read locks when we need a write
> lock (like I submitted for Bug #133220) is messy, and should be
> avoided.
>
> Hence I would like if bzrlib allowed write locks to be taken from
> within read locks.

Suppose we have this pattern of operations:

 lock_read
 a = read_tags()
 # x
 upgrade_lock
 a['foo'] = 'bar'
 write_tags(a)
 unlock

If another writer comes along at point x and changes the tag
dictionary, then those changes will be lost.  Read locks in bzr don't
exclude writers, with the exception of the dirstate OS lock and even
there it's something we want to relax.  (This is mostly a desirable
principle for this environment and anyhow it'd be hard to do otherwise
given all the filesystem environments we work in.)

We could safely upgrade by making sure that we refreshed our state
from disk after acquiring the lock, though that would tend to defeat
your goal of not reading it twice.  Ideally this would be done in a
way that made it hard for application code to get wrong.

-- 
Martin