FLOCKFILE(3POSIX)

💅 FLOCKFILE(3POSIX) — the POSIX Programmer's Manual, but make it group chat

okay bestie so this page is literally from the POSIX Programmer's Manual (you know, the FLOCKFILE(3POSIX) one) 🎀

---

🚨 PROLOG 🚨

so like, real talk before we get into it: this manual page is part of the POSIX Programmer's Manual. the Linux implementation of this interface may differ (so if you're on Linux, bestie, go consult the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not even be implemented on Linux at all. not me warning you first thing 🙈

---

✨ NAME ✨

flockfile, ftrylockfile, funlockfile — the stdio locking functions 🦋

---

🌸 SYNOPSIS 🌸

#include <stdio.h>

void flockfile(FILE *file);
int ftrylockfile(FILE *file);
void funlockfile(FILE *file);

like. that's it. that's the whole vibe. 👑

---

💖 DESCRIPTION 💖

so these functions shall provide for explicit application-level locking of stdio (FILE *) objects. a thread can use them to delineate a sequence of I/O statements that are executed as a unit. it's giving "this block is MINE, nobody else touch it" 💅

• flockfile() — shall acquire for a thread ownership of a (FILE *) object. periodt.
• ftrylockfile() — shall acquire for a thread ownership of a (FILE *) object if the object is available; ftrylockfile() is the non-blocking version of flockfile(). it's the "hey are you free? no? okay bye" of functions ✨
• funlockfile() — shall relinquish the ownership granted to the thread. and listen: the behavior is undefined if a thread other than the current owner calls the funlockfile() function. so like, don't do that. that's not your lock. that's not your man. 🚩

now here's the lore: the functions shall behave as if there is a lock count associated with each (FILE *) object. this count is implicitly initialized to zero when the (FILE *) object is created. the (FILE *) object is unlocked when the count is zero. when the count is positive, a single thread owns the (FILE *) object.

when flockfile() is called:

• if the count is zero, or
• if the count is positive and the caller owns the (FILE *) object,

then the count shall be incremented. otherwise, the calling thread shall be suspended, waiting for the count to return to zero. like, standing outside the club, no cap.

each call to funlockfile() shall decrement the count. this is what allows matching calls to flockfile() (or successful calls to ftrylockfile()) and funlockfile() to be nested. layers, bestie. onions. 🧅

and the last lil lore drop: all functions that reference (FILE *) objects — except those with names ending in _unlocked — shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these (FILE *) objects. iykyk 😌

---

🎀 RETURN VALUE 🎀

none for flockfile() and funlockfile(). they return nothing. they simply are. 🌈

the ftrylockfile() function shall return zero for success and non-zero to indicate that the lock cannot be acquired. so zero = slay, non-zero = not today. 💀

---

🍓 ERRORS 🍓

no errors are defined. iconic behavior honestly. zero drama. 🫶

the following sections are informative. (yes bestie, that means the good stuff below is informative, not normative — it's the commentary track, not the movie 🎬)

---

🌟 EXAMPLES 🌟

none. nope. absolutely none. the void. the emptiness. crickets 🦗

---

💜 APPLICATION USAGE 💜

applications using these functions may be subject to priority inversion, as discussed in the Base Definitions volume of POSIX.1‐2017, Section 3.291, Priority Inversion. so like, heads up. 👀

also, a call to exit() can block until locked streams are unlocked, because a thread having ownership of a (FILE*) object blocks all function calls that reference that (FILE*) object from other threads (except those with names ending in _unlocked) — including calls to exit(). so yeah, your exit could just be standing there waiting. awkward. 😭

---

🧚 RATIONALE 🧚

so the flockfile() and funlockfile() functions provide an orthogonal mutual-exclusion lock for each FILE. the ftrylockfile() function provides a non-blocking attempt to acquire a file lock, analogous to pthread_mutex_trylock(). sister functions fr fr. 👯

these locks behave as if they are the same as those used internally by stdio for thread-safety. this both:

1. provides thread-safety of these functions without requiring a second level of internal locking, and
2. allows functions in stdio to be implemented in terms of other stdio functions.

efficient AND elegant? we love a two-for-one. ✨

now, the serious part, because bestie i need you locked in for this one: application developers and implementors should be aware that there are potential deadlock problems on FILE objects. for example, the line-buffered flushing semantics of stdio (requested via {_IOLBF}) require that certain input operations sometimes cause the buffered contents of implementation-defined line-buffered output streams to be flushed. if two threads each hold the lock on the other's FILE, deadlock ensues. 💀💀💀

this type of deadlock can be avoided by acquiring FILE locks in a consistent order. in particular, the line-buffered output stream deadlock can typically be avoided by acquiring locks on input streams before locks on output streams if a thread would be acquiring both. order matters, bestie. always has. 🎯

in summary: threads sharing stdio streams with other threads can use flockfile() and funlockfile() to cause sequences of I/O performed by a single thread to be kept bundled. the only case where the use of flockfile() and funlockfile() is required is to provide a scope protecting uses of the *_unlocked functions/macros. this moves the cost/performance tradeoff to the optimal point. chef's kiss. 👨‍🍳💋

---

🔮 FUTURE DIRECTIONS 🔮

none. the future is... also nothing. we stay present. 🧘

---

👀 SEE ALSO 👀

• exit()
• getc_unlocked()
• the Base Definitions volume of POSIX.1‐2017, Section 3.291, Priority Inversion
• <stdio.h>

---

📜 COPYRIGHT 📜

portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group.

in the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. the original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. to report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

k that's the whole page bestie, go lock some files responsibly and please, please don't call funlockfile() on someone else's lock, i'm begging 🙏

mwah 💋 this has been IEEE/The Open Group, 2017, signing off from FLOCKFILE(3POSIX) — stay unlocked (metaphorically) 🌸🦋💖