🚀 go-pugleaf

In article <2170@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes:
>In article <341@harvard.ARPA> sasaki@harvard.UUCP (Marty sasaki) writes:
>>VMS (no flames please) has such a lock manager. The idea is that locks
>>are named when they are created. There are primities to lock, unlock,
>>and wait on locks. All that is required is that users agree on a
>
>Seems to me that Unix already has something that comes very very close
>to this.
>Does System V and friends have exclusive opens?

Well, yes, but why bother? The desired quality is a resource lock, not 
yet-another-UNIX-hack-to-get-around-missing-facility. 
System V r2 has a series of mechanisms
used for inter-process communication, known collectively as 'Sys V IPC'.
The three items are: dynamic shared memory, message queues, and semaphores.
A semaphore sounds like just the thing you need: It is maintained in the
kernel (read: fast for IPC, and inviolate by user code). The multiple processes
using the semaphore can query its current value, atomically increment or
decrement the value, or block waiting for a given value. A mechanism is
also built in so that if a process exits or is killed unexpectedly, the 
semaphore is changed to be 'untouched' (this is selectable),
so that the arbitrated-for resource will not become unavailable. 

Utilities are provided that can query and change the IPC structures, so
if something goes wrong, you can fix it.

Also, semaphores are a data structure, so they go away after a reboot or crash.
Ever have a machine crash while something that uses lock files (like uucp)
is running? Finding lock files and blowing them away is unacceptable.

Jeff Carter
MASSCOMP
1 Technology Park
Westford, MA 01886
...!{ihnp4|decvax|harvard}!masscomp!carter