[PATCH] Singleton Branches

John Arbash Meinel john at arbash-meinel.com
Thu May 26 16:52:35 BST 2005


Martin Pool wrote:

>On 25 May 2005, John A Meinel <john at arbash-meinel.com> wrote:
>
>
>
>>>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.
>>>
>>>
>>flock specifically allows you to upgrade a read lock to a write lock. On
>>win32 you cannot upgrade a lock.
>>
>>
>
>I think there may be an API (perhaps not exposed in Python) which
>allows upgrading.  But the potential deadlock exists anyhow.
>
>
...

>OK, so you can avoid[*] the deadlock if you say that all callers must
>be prepared to have their request to upgrade result in loss of the
>lock altogether, causing the caller to probably either fall altogether
>or start again from the begining with the proper lock.  (And once you
>do that, you don't actually need lock upgrading anymore and perhaps
>you should not bother, except that it's a complexifying optimization
>for the uncontested case.)
>
>[*] http://www.cs.jhu.edu/~yairamir/cs418/os4/tsld011.htm
>
>

I'm just fine with throwing out lock upgrading. I can't come up with a
really good use case. If you change to having locks be explicit, then
you don't have these problems. It was just a way to handle people trying
to lock the same branch multiple times with different Branch() objects.

>
>
>>Well, one nice possibility of a singleton, is that you can upgrade the
>>singleton and everyone goes through the same object and sees the same
>>updates.
>>
>>
>
>A singleton is not really a total solution because it won't be unique
>among all Python processes, and on the other hand there might be
>uncoordinated Python thread-like entities in a single process that
>don't want a singleton.
>
>
A singleton tied to an OS lock seems to get pretty close to unique among
all processes.

>I can see that some applications will want to naively try to create
>branch objects and have them uniquified, but I'm not sure that all
>will want that, or that it really belongs in the Branch class.
>
>
>
It is very easy in code to have multiple requests for the same branch
object without realizing it. Because the filesystem is sometimes the
point of coordination, not the python code. Two portions of code saying
give me information about this file will probably have to allocate a
branch object to get it.

I only really need a singleton Lock object, though it seemed reasonable
to put that in the Branch object. I don't really know what ideas you
have about how Branch is supposed to evolve, what methods/members etc it
will contain. I can see that if you are starting to add data to a
branch, you might have an in-memory representation that needs to evolve,
but not be exposed to anyone else until it is done.

I'm still concerned about revfile appending. The last comment you made
was "two processes can concurrently append to the same file, they just
don't know where their data is". While probably completely true, the
last portion is what makes it worthless. The whole point is that I can
put my new revision information into the file, and then reference it
later. I think the one big lock approach (.bzr/branch-lock) works fine.
But you could also be more fine-grained and take out an explicit lock on
each file as you are appending to it. One potentially useful advantage
of the per-file locks is if you end up with shared multi-branch files
(for instance, through hard-linking). You have mentioned that there is
no problem with having extra information in a rev-file, as long as you
don't reference it in the branch. Which means that the branch-lock no
longer locks the file from all possible modifications. So you should
lock the file itself. You probably won't lock it for long, and if you
only lock it exclusive, and only do one file at a time, you should avoid
deadlocks.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050526/93bac392/attachment.pgp 


More information about the bazaar mailing list