[PATCH] Singleton Branches

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John,

John A Meinel wrote:
>              # On some platforms (*cough* win32 *cough*), upgrading a lock requires unlocking it first
On any platform, attempting to upgrade a lock without unlocking first
can lock you hard.

1. process A acquires read lock
2. process B acquires read lock
3. process A attempts to acquire write lock.  Blocked on B.
4. process B attempts to acquire write lock.  Blocked on A.  Stalemate.

This means that you must unlock before you lock.  But when you unlock,
it's possible for state to change before you lock again, and it's
*necessary* for that to be possible, so you don't get into the situation
described above, because in the situation described above, one of the
processes has to lose the fight.

But you mustn't have the on-disk state change while you think you're
holding a lock-- that's the point of the lock.  So you can't use a
singleton to refer to a branch if you want to be able to upgrade the
lock, because if you already have the branch open and the disk state
state changes, that would be bad.

If we assume you want to be able to write to the branch sometimes, and
it's a singleton, then it must always be write-locked.  Otherwise, I
don't think it can be a singleton, because you have to lose all your
state when you unlock.  Maybe the flyweight pattern would work for this,
but not singleton.

So this is why I didn't want to retain any state when trying to change
the locking of a branch.  The intent was to force people to lock a
writable version of the branch from the get-go, and never upgrade locks
mid-stream.  I admit I'm not any kind of expert on locking, so if
there's somthing wrong here, please let me know.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClRmC0F+nu1YWqI0RAu0lAJ4oej0PyN4jAcvb33PTA/DyujYIEQCfbvul
bDIqad0r2Y2ZHic0sMGp6qs=
=jXGP
-----END PGP SIGNATURE-----