[svk-devel] Re: a few locking-related issues

[Michael Brouwer]

The strategy sounds resonable to me.

However from a high level view wouldn't it make more sense to provide 2 APIs
to svk itself:

1) Access to and locking of the depotmap
2) Access to and locking of checkout paths

This split would make it easier to refactor the checkout code to store the
Data::Hierarchy for a given working copy locally in that working copy (f.e.
in a SVK or .svk dir) while keeping the depotmap and depots where they are
today.

Michael


On 8/18/06, David Glasser <glasser at mit.edu> wrote:
>
> So what I'm trying to implement for SVK's locking strategy (which will
> be added to internal pod docs) follows. Note that neither SVK nor the
> patch I just sent fully implements this; I have another patch that I
> think does but I'd like to test it out on Win32 first.
>
> Do people think this is a good locking strategy?
>
> SVK Locking strategy:
>
> Note: this is *not* about "mirror locks" or "Subversion locks": this
> is about locking access to SVK's statefile ($SVKROOT/config) and
> checkouts.
>
> SVK has an application-level "giant" lock, which is a file
> ($SVKROOT/lock).  "Holding" the giant lock means having an open
> filehandle to it, locked exclusively.  The process that holds the
> giant lock writes its PID into the giant lock file for informational
> purposes.  The giant lock controls all access to the statefile; SVK
> should never read or write the statefile without holding the giant
> lock.
>
> When an SVK command is executed, the following sequence of events
> happens (note that commands like "svk help" and "svk --version" which
> will never need access to the statefile or checkout are special-cased
> to not do any locking):
>
> * Acquire the giant lock; if this fails for several seconds, die.
>
> * Read the statefile into memory.
>
> * Call the command's parse_args method.
>
> * Call the command's lock method.  The command can choose one of three
> options:
>
> ** Commands which need to make drastic changes to the statefile
>    (including depotmap changes) should call the keep_giant method;
>    this will make SVK hold the giant lock for the entire command. This
>    should be avoided if possible, especially for commands which take a
>    non-constant amount of time.
>
> ** Commands which need to access a checkout path (either the actual
>    checkout on disk or its record in the Data::Hierarchy object in the
>    statefile) should call lock on their XD (either directly or through
>    something like lock_coroot); they may call this on multiple paths
>    if they wish. This dies if the statefile that they have already
>    read in indicates that another process has locked those checkout
>    paths. Otherwise, it marks those paths as locked to this process in
>    the in-memory Data::Hierarchy of the XD.
>
> ** Commands which don't depend on checkout paths can just do nothing.
>
> * If the command's locking phase locked any checkout paths, write the
>   statefile out to disk.
>
> * Unless the command made a keep_giant call, drop the giant lock.
>
> * Call the command's run method.
>
> * If the command was keeping the giant lock, write out the statefile,
>   drop the giant lock, and exit.
>
> * If the command had locked any paths, get the giant lock, read in the
>   statefile, merge in any changes to the Data::Hierarchy object *in
>   locked paths only* that the command made, write out the statefile,
>   and drop the giant lock.
>
>
> --dave
>
>
> --
> David Glasser | glasser at mit.edu | http://www.davidglasser.net/
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/svk-devel/attachments/20060818/8f715417/attachment.htm