1FLOCKFILE(3P)              POSIX Programmer's Manual             FLOCKFILE(3P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10

NAME

12       flockfile, ftrylockfile, funlockfile - stdio locking functions
13

SYNOPSIS

15       #include <stdio.h>
16
17       void flockfile(FILE *file);
18       int ftrylockfile(FILE *file);
19       void funlockfile(FILE *file);
20
21

DESCRIPTION

23       These functions shall provide for explicit application-level locking of
24       stdio  (  FILE  *)  objects. These functions can be used by a thread to
25       delineate a sequence of I/O statements that are executed as a unit.
26
27       The flockfile() function shall acquire for a thread ownership  of  a  (
28       FILE *) object.
29
30       The ftrylockfile() function shall acquire for a thread ownership of a (
31       FILE *) object if the object is available;  ftrylockfile()  is  a  non-
32       blocking version of flockfile().
33
34       The  funlockfile()  function  shall relinquish the ownership granted to
35       the thread. The behavior is undefined if a thread other than  the  cur‐
36       rent owner calls the funlockfile() function.
37
38       The  functions shall behave as if there is a lock count associated with
39       each ( FILE *) object. This count is  implicitly  initialized  to  zero
40       when  the ( FILE *) object is created. The ( FILE *) object is unlocked
41       when the count is zero.  When the count is positive,  a  single  thread
42       owns  the ( FILE *) object. When the flockfile() function is called, if
43       the count is zero or if the count is positive and the caller owns the (
44       FILE *) object, the count shall be incremented.  Otherwise, the calling
45       thread shall be suspended, waiting for the count  to  return  to  zero.
46       Each  call  to  funlockfile()  shall  decrement  the count. This allows
47       matching calls to flockfile() (or successful calls  to  ftrylockfile())
48       and funlockfile() to be nested.
49
50       All  functions that reference ( FILE *) objects shall behave as if they
51       use flockfile() and funlockfile() internally  to  obtain  ownership  of
52       these ( FILE *) objects.
53

RETURN VALUE

55       None for flockfile() and funlockfile().
56
57       The  ftrylockfile() function shall return zero for success and non-zero
58       to indicate that the lock cannot be acquired.
59

ERRORS

61       No errors are defined.
62
63       The following sections are informative.
64

EXAMPLES

66       None.
67

APPLICATION USAGE

69       Applications using these functions may be subject  to  priority  inver‐
70       sion,    as    discussed    in   the   Base   Definitions   volume   of
71       IEEE Std 1003.1-2001, Section 3.285, Priority Inversion.
72

RATIONALE

74       The flockfile()  and  funlockfile()  functions  provide  an  orthogonal
75       mutual-exclusion  lock  for each FILE. The ftrylockfile() function pro‐
76       vides a non-blocking attempt to  acquire  a  file  lock,  analogous  to
77       pthread_mutex_trylock().
78
79       These  locks behave as if they are the same as those used internally by
80       stdio for thread-safety. This  both  provides  thread-safety  of  these
81       functions  without  requiring  a  second  level of internal locking and
82       allows functions in stdio to be implemented in  terms  of  other  stdio
83       functions.
84
85       Application  writers  and  implementors  should be aware that there are
86       potential deadlock problems on FILE objects.  For  example,  the  line-
87       buffered  flushing  semantics of stdio (requested via {_IOLBF}) require
88       that certain input operations sometimes cause the buffered contents  of
89       implementation-defined  line-buffered  output streams to be flushed. If
90       two threads each hold the lock on the other's  FILE,  deadlock  ensues.
91       This  type of deadlock can be avoided by acquiring FILE locks in a con‐
92       sistent order. In particular, the line-buffered output stream  deadlock
93       can  typically  be  avoided  by acquiring locks on input streams before
94       locks on output streams if a thread would be acquiring both.
95
96       In summary, threads sharing stdio streams with other  threads  can  use
97       flockfile()  and funlockfile() to cause sequences of I/O performed by a
98       single thread to be kept bundled.  The  only  case  where  the  use  of
99       flockfile()  and  funlockfile()  is required is to provide a scope pro‐
100       tecting uses of  the  *_unlocked()  functions/macros.  This  moves  the
101       cost/performance tradeoff to the optimal point.
102

FUTURE DIRECTIONS

104       None.
105

SEE ALSO

107       getc_unlocked(),   putc_unlocked(),  the  Base  Definitions  volume  of
108       IEEE Std 1003.1-2001, <stdio.h>
109
111       Portions of this text are reprinted and reproduced in  electronic  form
112       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
113       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
114       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
115       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
116       event of any discrepancy between this version and the original IEEE and
117       The Open Group Standard, the original IEEE and The Open Group  Standard
118       is  the  referee document. The original Standard can be obtained online
119       at http://www.opengroup.org/unix/online.html .
120
121
122
123IEEE/The Open Group                  2003                        FLOCKFILE(3P)
Impressum