Re: On ref locking

> 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.