dgflock(3c) DG/UX 4.30 dgflock(3c)
NAME
dg_flock - apply or remove an advisory lock on an open file
in DG/UX
SYNOPSIS
#include <sys/types.h>
#include <sys/file.h>
#define LOCKSH 1 /* shared lock */
#define LOCKEX 2 /* exclusive lock */
#define LOCKNB 4 /* don't block when locking */
#define LOCKUN 8 /* unlock */
dgflock(fildes, operation)
int fildes, operation;
DESCRIPTION
Dgflock applies or removes an advisory lock on the file
associated with the file descriptor fildes, depending on the
operation specified. A lock is applied by specifying an
operation parameter that is the `exclusive or' of LOCK_SH or
LOCK_EX and, possibly, LOCK_NB. Operation should be LOCK_UN
to unlock an existing lock.
Advisory locks allow cooperating processes to perform
consistent operations on files, but do not guarantee
consistency (i.e., processes may still access files without
using advisory locks, possibly resulting in
inconsistencies).
The locking mechanism allows two types of locks: shared
locks and exclusive locks. A shared lock is similar to a
read lock as described in fcntl(2). That is, an exclusive
lock cannot be applied as long as a shared lock is in
effect. An exclusive lock is similar to a write lock in
that no other lock can be applied as long as the exclusive
lock is in effect.
At any time, multiple shared locks may be applied to a file,
but at no time are multiple exclusive, or both shared and
exclusive, locks allowed simultaneously on a file.
A shared lock may be upgraded to an exclusive lock, and vice
versa, simply by specifying the appropriate lock. This is
an atomic operation; that is, the lock is not released
during the change.
The child of a process acts independently of its parent
process in regards to locks. More specifically, the child
of a process does not inherit locks; and if a child unlocks
a file, it does not release the lock of the parent.
Licensed material--property of copyright holder(s) Page 1
dgflock(3c) DG/UX 4.30 dgflock(3c)
Requesting a lock on an object that is already locked
normally causes the caller to be blocked until the lock may
be acquired. If LOCK_NB is included in operation, then this
block will not happen; instead the call will fail and the
error EWOULDBLOCK will be returned.
Fildes must be open for reading in order to obtain a shared
lock, open for writing to obtain an exclusive lock.
NOTES
Locks are on files, not file descriptors. That is, file
descriptors duplicated through dup(2) do not result in
multiple instances of a lock.
Blocked processes awaiting a lock may be awakened by
signals.
Note the following departures from Berkeley 4.2
specifications for dgflock compared to the BSD flock call:
Dgflock can return EDEADLK whereas 4.2 BSD would
simply deadlock.
Upgrading a lock will be an atomic operation. That is,
a lock is not released to upgrade that lock.
A child process does not inherit locks from its parent
process.
Fildes must be open for reading to obtain a shared
lock, open for writing to obtain an exclusive lock.
Dgflock and lockf are mutually compatible until lockf
has a mandatory locking option.
RETURN VALUE
If the operation was successful, 0 is returned; on an error,
a -1 is returned and an error code is left in the global
location errno.
ERRORS
The dgflock call fails if:
[EWOULDBLOCK] The file is locked and the LOCK_NB
option was specified.
[EBADF] The argument fildes is an invalid
descriptor, or its mode does not allow a
request of the given lock type.
[EINTR] An interrupt was received before the
lock was obtained.
Licensed material--property of copyright holder(s) Page 2
dgflock(3c) DG/UX 4.30 dgflock(3c)
[EINVAL] The argument fildes refers to an object
other than a file.
[EDEADLK] Awaiting the lock would cause a
deadlock.
SEE ALSO
open(2), close(2), dup(2), exec(2), fork(2), fcntl(2).
Licensed material--property of copyright holder(s) Page 3