flock(3c)
_________________________________________________________________
flock
apply or remove an advisory lock on an open file in DG/UX
_________________________________________________________________
SYNTAX
#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 */
flock(fildes, operation)
int fildes, operation;
DESCRIPTION
Flock 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
DG/UX 4.00 Page 1
Licensed material--property of copyright holder(s)
flock(3c)
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 error EWOULDBLOCK will
be returned.
Filedes 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 the flock call:
Flock 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.
Filedes must be open for reading to obtain a shared lock,
open for writing to obtain an exclusive lock.
Flock 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 flock call fails if:
DG/UX 4.00 Page 2
Licensed material--property of copyright holder(s)
flock(3c)
[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.
[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).
DG/UX 4.00 Page 3
Licensed material--property of copyright holder(s)