[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locking entire tree for write

From: Paul Sander
Subject: Re: locking entire tree for write
Date: Tue, 14 Oct 2003 14:50:42 -0700

>--- Forwarded mail from address@hidden

>[ On Tuesday, October 14, 2003 at 13:05:58 (-0400), Derek Robert Price wrote: ]
>> Subject: Re: locking entire tree for write
>> If nobody has any comments on this, I'm going to check in the correction
>> on feature soon.
>> | Correct me if I am wrong, but there is no good reason for the
>> | lock_tree_for_write calls in admin.c, edit.c, and watch.c.  The three
>> | files contain four calls and all are of the form:
>> |
>> | ~    lock_tree_for_write
>> | ~    start_recursion(...CVS_LOCK_NONE...)
>> | ~    Lock_Cleanup
>> |
>> | with no intervening calls.  I believe that in all four locations this
>> | could be replaced with the single call to:
>> |
>> | ~    start_recursion(...CVS_LOCK_WRITE...)
>> |
>> | as cvs tag and rtag do and that this would be more efficient, allowing
>> | only a directory at a time to be locked rather than locking an entire
>> | tree for the duration of the entire operations.

>Yes, more efficient, but also more dangerous.

>I don't know (and don't care) about anything to do with 'edit' and
>'watch'.  However in theory even 'tag' and 'rtag' should always first
>lock-for-write the whole module they're oerating on, even for the simple
>case of adding a new tag (some other concurrent user can easily
>encounter problems when trying to use the new tag, or the old tag in the
>case of a rename or delete, or even an existing tag in the case of a

Believe it or not, I actually agree with Greg on this one.  However, there
are possible implementations that can eliminate the risk.

For example, locking tags in the same what directories are locked and
performing the same kinds of waits prevent users from using tags in
incompatible ways, such as fetching by tag while updating a tag.

Features such as rtag that don't identify in advance the revisions they
act upon can also rely on branch/timestamp pairs to prevent multiple update
problems when users sneak in a commit while rtag processes a different
directory of the same module.

Version tags could also be reimplemented not as symbolic names of specific
revisions but as branch/timestamp pairs.  Branch tags apply to their sprout
points, which can be identified similarly.

It's perhaps too much to ask to reimplement tags as in the last paragraph,
but the first two items are relatively easy to implement.

There has been a lot of research over the years on topics such as "degrees
of isolation" and "lock free algorithms," and CVS could benefit from some
of it.

>--- End of forwarded message from address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]