dg_flock(3C) DG/UX 5.4R3.00 dg_flock(3C)
NAME
dgflock - apply or remove an advisory lock on an open DG/UX file
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 either LOCK_SH or LOCK_EX and, possibly, LOCK_NB. LOCK_SH
and LOCK_EX are mutually exclusive. 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.
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 errno EACCES will be set.
Fildes must be open for reading in order to obtain a shared lock,
Licensed material--property of copyright holder(s) 1
dg_flock(3C) DG/UX 5.4R3.00 dg_flock(3C)
open for writing to obtain an exclusive lock.
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.
DIAGNOSTICS
The dgflock call fails if:
[EACCES] 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.
[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).
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.
Dgflock will return EACCES instead of EWOULDBLOCK if using
LOCK_NB and a lock is already held.
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.
Licensed material--property of copyright holder(s) 2
dg_flock(3C) DG/UX 5.4R3.00 dg_flock(3C)
Licensed material--property of copyright holder(s) 3