Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: ABIs and the futurrrr of UNIX(tm)
Message-ID: <7608@brl-smoke.ARPA>
Date: 2 Apr 88 17:40:27 GMT
References: <431@micropen> <185@tscs.UUCP> <587@garth.UUCP> <186@sdeggo.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <186@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes:
>At the heart of my code is a set of database routines that use flock() and
>lockf() calls to keep things in order.  On SunOS lockf() has an enforced
>mode, where the kernel will make routines that attempt to read/write a
>locked section block until it is unlocked.  ICON choose to implement the
>Sys V version instead which does not have an enforcement mode.

I don't know the specifics of the ICON system, but I do know about
System V file/record locking.  The current release of UNIX System V
provides improved locking control via a subset of the fcntl() system
call.  This appeared just after SVR2.0; it includes "read" (shared)
and "write" (exclusive) advisory (cooperative) locks on any block of
bytes or the whole file.  More recently, mandatory locking has been
added; it is enabled on a per-file basis by setting the Set-GID bit
on a file that does not have the Group-Execute bit set.  This causes
the same fcntl() operations to be taken as mandatory locks instead of
cooperative locks.

Check your system documentation to see if any of this has been
provided.  It's well enough designed that IEEE Std 1003.1 decided
to pick up most of it for the POSIX standard.