Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site gatech.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!floyd!cmcl2!seismo!hao!hplabs!sdcrdcf!sdcsvax!akgua!gatech!jeff
From: jeff@gatech.UUCP (Jeff Lee)
Newsgroups: net.unix-wizards
Subject: File locking under Unix
Message-ID: <8034@gatech.UUCP>
Date: Thu, 7-Jun-84 17:34:41 EDT
Article-I.D.: gatech.8034
Posted: Thu Jun  7 17:34:41 1984
Date-Received: Sun, 10-Jun-84 01:45:14 EDT
Organization: Georgia Tech School of ICS, Atlanta
Lines: 27

I'm  almost finished with a general-purpose tree-structured accounting pac-
kage for (what I hope is) a relatively generic  version  of  Unix.   I  im-
plemented  a  simple locking procedure for the master accounting file using
links.  I keep a lock file around to which each  process  will  attempt  to
link.   Whenever  a  process  sees that the file is busy, it waits 1 second
(the smallest interval) and then attempts  it  again.   Currently  it  will
retry  9  times  before  it announces failure to the calling routine, but I
have tested it with 15 times.  This means that a process may have  to  wait
up  to  15  seconds before it can access the master file, which is a pretty
long time considering that each operation only takes .2 to .25  seconds  to
complete.   The  problem  is  this, when I cranked up 5 processes that were
beating on the master file pretty heavily, I was having processes  starving
(often).   I  knew  that  it  didn't prevent this but I had no idea that it
would be quite so bad.  I have considered setting an alarm for  10  seconds
and  linking  as  much as possible during that time to try to eliminate the
synchronizing that seems to be hap- pening.  All that needs to happen is to
get the file once in 10 seconds to prevent starvation.

Does anyone else have a file locking scheme that will ensure  mutual  excl-
usion and prevent starvation?  Semaphores would be nice but we are assuming
no  such  beasties  in  most  Unix  implementations.  No frills needed.  No
record locking or N readers or 1 writer function.  This can be Canada  Dry,
not Perrier.
-- 
Jeff Lee
CSNet:	Jeff @ GATech		ARPA:	Jeff.GATech @ CSNet-Relay
uucp:	...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff