Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!clyde.concordia.ca!IRO.UMontreal.CA!goutier
From: goutier@IRO.UMontreal.CA (Claude Goutier)
Newsgroups: comp.unix.wizards
Subject: Re: Is HDB locking safe?
Message-ID: <1990Aug16.091730.16827@IRO.UMontreal.CA>
Date: 16 Aug 90 09:17:30 GMT
References: <577@oglvee.UUCP> <4024@rtifs1.UUCP>
Sender: news@IRO.UMontreal.CA
Reply-To: goutier@jsp.umontreal.ca (Claude Goutier)
Organization: Universite de Montreal
Lines: 33

In article <4024@rtifs1.UUCP> trt@rti.rti.org (Thomas Truscott) writes:
>
>A crucial detail in recovering from a breakdown in the lock protocol
>is avoiding a race between two or more processes that are simultaneously
>attempting recovery.  Usually a strategic pause is all that is needed,
>and as you can see in the HDB code below there is just such a pause.
>
> ...
>
>The HDB code is nice, but does have flaws:
>(a) A "sleep(1);" is not enough to avoid a race on a very busy system.
>(b) Lock recovery is obscure, so the sleep() call should be commented.
>(c) Protocol breakdown is a bad thing, and should be reported:
>	logent(lockfile, "DEAD LOCK");
>The 4.3 BSD ulockf.c routine has all of these nice features.
>
>	Tom Truscott

If a sleep(1) is not long enough, why does a sleep(5) is?

If something is not prohibited to happen by construction (read solid
and serious interlock), whatever small the probability of it to happen,
it WILL happen!

One should never try to be smarter than a race condition. The only way
is to use true and solid interlocks (which should be provided in the
kernel and with the cooperation of the hardware). Have you ever programmed
on a machine with a fast CPU and ten peripheral processors all accessing
the same memory at the same time ?
--
 Claude Goutier             Services informatiques, Universite de Montreal
                            C.P. 6128, Succ "A",         Montreal (Quebec)
 goutier@jsp.umontreal.ca   Canada      H3C 3J7