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

[David Glasser]

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/