Re: On ref locking

[Daniel Barkalow <barkalow@iabervon.org>]

On Mon, 25 Sep 2006, Junio C Hamano wrote:

> The comments you added to the strawman I sent suggested use of
> rather heavyweight locks, which made me feel we were somehow
> going in a wrong direction.  Before going into the details of
> branch removing, let's first see if we can summarize what kind
> of guarantee we would want from ref updates.  The current
> locking scheme is very carefully and nicely done by Linus and
> Daniel Barkalow around June last year, and I do not want to lose
> good property of it.
> 
>  - When reading and/or listing refs you do not need to acquire
>    any lock.
> 
>  - When you are going to update an existing $ref, you create
>    $ref.lock, and do a compare-and-swap.
> 
> What the latter means is that an updater:
> 
>  (1) first learns the current value of the $ref, without
>      locking;
> 
>  (2) decides based on the knowledge from (1) what the next value
>      should be;
> 
>  (3) gets $ref.lock, makes sure $ref still is the value it
>      learned in (1), updates it to the desired value and
>      releases the lock.
> 
> The above 3-step sequence prevents updater-updater races with an
> extremely short critical section.  We only need to hold the lock
> while we do compare and swap.

I remember having a certain amount of disagreement over whether it's 
better to actually take the lock in (1), and hold it through (2), or only 
verify that it didn't change in (3) after taking the lock for real. If 
there's nothing substantial going on in (2), it doesn't matter. If users 
are producing content (e.g., git tag), they may want to make sure that 
nobody else is in the middle of writing something that would conflict.

I think I'd advocated getting the lock early if you're going to want it, 
and I don't remember what the convincing argument on the other side was 
for the cases under consideration at the time, beyond it not mattering 
significantly.

Note that we make sure to remove the lock when aborting due to signals 
(assuming we get a chance), so the size of the critical section doesn't 
matter too much to the chance of it getting left locked inappropriately. 
Of course, this is harder to do with the core code for a shell script than 
for C code.

	-Daniel
*This .sig left intentionally blank*