In message <firstname.lastname@example.org>,
Brent Chapman writes:
>John Rouillard proposed a different queued locking mechanism a few days
>ago. I haven't analyzed the proposal in great depth, but two things struck
>me as problematic about it. First, it appears to require maintaining the
>queue as a file, and locking the queue file (using the existing shlock
>mechanism) when you want to update it; this seems to me to simply move the
>simultaneous-access problem from the main file to the queue file.
True, but the queue file (the one holding the current queue length) is
only locked for a short period of time, so while it is possible to
have the same contention issues, the total number of trials avalialbe
should be greater.
>it appears to require renaming a bunch of files every time the queue
>changes, to reflect processes moving up in the queue; this seems like it
>could cause a lot of unnecessary filesystem activity.
I don't know about unecessary 8-), but it will cause file system
>What I propose instead is the following, which is an extension to the
>existing locking mechanism (that is, I think it can be incorporated into
>the shlock code without any interface changes). Basicly, when a process
>creates its temporary lock file, name the file "Q.<time>.<pid>.<filename>"
>(this is why I say it won't work on systems limited to 14-character
>filenames) instead of simply "L.<pid>" the way it is in the old scheme.
>Then, just as now, try to hard link "L.<filename>" to this temporary file.
>If the link succeeds (which it normally will, on a lightly-loaded system),
>you now own the lock, without really having done any more work than before
>(you had to construct a slightly more complex filename, but that's all).
>When a process unlocks a file, it should send a signal (SIGUSR1, for
>example) to the next waiting process, telling the waiting process that the
>lock is now available. The original process can determine the next process
>by simply looking for the first "Q.<time>.<pid>.<filename>" file with an
>appropriate <filename>; that's why put the time in the queue filename, so
>that they sort properly.
Hmm, interesting the time would have to be something like:
March 28 1995 11:34 and 25 seconds. So I readdir the directory when I
am done looking for any other files that match the template, and sort
the file names. The one at the top is my next victim. If it isn't
present, remove the file, and continue with the next one at the top of
>The pid is there so that the original process
>knows who to signal. If that process is dead, delete its Q.* file, and
>signal the next process; repeat until you find one still waiting, or have
>cleared all the Q.* files.
Good idea, except that I'm not sure that signal will work exactly
right under some of the os's people now have majordomo running
on. (e.g. VMS Unixware, windows NT come to mind.) Also some old SVR3
boxes don't have signal(0), but that's not a hassle since I can always
parse the ps output if need be to see if the process still exists.
Alan Stebbins locking code looked good. The one issue I have is
whether or not it will become expensive to manipulate the semaphore
queuing file or not. I just did some time trials on a heavily loaded
decstation and on a sparc 20 under solaris 2.3, and it doesn't seem to
be that bad.
We only use the mechanism on one host, it is be trivial to check to see
if the process existed. However support for multiple host code
compilcates this somewhat since a timeout is needed rather than
checking for a pid when looking at a remote locking process. If the
machine housing the filesystem goes down for timeout minutes, and then
things start back up, the process on the remote machine will still
think it has a lock, but any new processes starting up will see the
lock as being stale, and will break it leading to unknown
consequences. Also, although it does involve more disk activity than
Brent's scheme (writing and scanning the file), it seems to be about
equal to the amount of work done in traversing a directory in Brent's
scheme, or my scheme.
Can people please look at Alan's suggested scheme for locking and see
if they have any problems with it. If not, then I think that will be
the scheme I adopt for testing purposes.
Senior Systems Administrator IDD Information Services
email@example.com Waltham, MA (617) 890-7227 x337
(617) 487-3937 (Direct)
Senior Systems Consultant (SERL Project) University of Massachusetts at Boston
firstname.lastname@example.org (preferred) Boston, MA, (617) 287-6480
My employers don't acknowledge my existence much less my opinions.