PTHREAD...CEILING(3POSIX)

💅 PTHREAD...CEILING — the POSIX girlies' guide to mutex priority ceilings ✨

okay so bestie, before we even get into it: this page lives in the POSIX Programmer's Manual, okay? like, it's the POSIX manual. and real talk — the Linux implementation of this interface may differ, so pls go check the corresponding Linux manual page for the actual Linux tea 🫖. or honestly the interface might not even be implemented on Linux at all. no cap. so vibe check first, always.

---

✨ NAME ✨

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling — get and set the priority ceiling of a mutex (and yes this is a REALTIME THREADS situation, we're in our realtime era 💖)

---

🎀 SYNOPSIS 🎀

#include <pthread.h>

int pthread_mutex_getprioceiling(const pthread_mutex_t *restrict mutex,
    int *restrict prioceiling);
int pthread_mutex_setprioceiling(pthread_mutex_t *restrict mutex,
    int prioceiling, int *restrict old_ceiling);

---

🦋 DESCRIPTION 🦋

so pthread_mutex_getprioceiling() is the lil reader — it shall return the current priority ceiling of the mutex. that's it, that's the whole job, she's just peeking 👀.

now pthread_mutex_setprioceiling() is the main character here. she shall attempt to lock the mutex as if by a call to pthread_mutex_lock(), except — and this is the lil plot twist — the process of locking the mutex need not adhere to the priority protect protocol. like she's doing her own thing, respectfully.

once she's acquired the mutex, she shall change the mutex's priority ceiling and then release the mutex as if by a call to pthread_mutex_unlock(). so it's a lock → glow-up → unlock situation, iconic behavior honestly 💅.

and when that change is successful? the previous value of the priority ceiling shall be returned in old_ceiling. so you get the receipts of what it used to be 🧾.

real talk though: if pthread_mutex_setprioceiling() fails, the mutex priority ceiling shall not be changed. nothing happens, we stay as we were, no chaos.

---

🌸 RETURN VALUE 🌸

if it works? both pthread_mutex_getprioceiling() and pthread_mutex_setprioceiling() shall return zero — slay 🎀. otherwise, an error number shall be returned to indicate the error. so no silent failing bestie, she will tell you.

---

🔥 ERRORS 🔥

these functions shall fail if:

• EINVAL — the protocol attribute of mutex is PTHREAD_PRIO_NONE. she said no protocol, she said none, periodt.
• EPERM — the implementation requires appropriate privileges to perform the operation and the caller does not have appropriate privileges. like sorry babe you don't have the clearance for this room 💀.

and the pthread_mutex_setprioceiling() function shall fail if:

• EAGAIN — the mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded. too many locks, girl, we're at capacity 😭.
• EDEADLK — the mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. you already have it!! you're holding it!! ma'am!!
• EINVAL — the mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling, and the implementation adheres to the priority protect protocol in the process of locking the mutex. so you're literally too powerful for this mutex, and the protocol is like "nope 🙈".
• ENOTRECOVERABLE — the mutex is a robust mutex and the state protected by the mutex is not recoverable. it's giving unsalvageable, we can't fix this one 💀.
• EOWNERDEAD — the mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock. the mutex lock shall be acquired by the calling thread, and it's up to the new owner to make the state consistent (see pthread_mutex_lock()). so you inherited this mess, bestie, and now it's your responsibility to clean it up 🫶.

the pthread_mutex_setprioceiling() function may fail if:

• EDEADLK — a deadlock condition was detected. yikes 🚨.
• EINVAL — the priority requested by prioceiling is out of range. that number's not valid babe, put it back.
• EOWNERDEAD — the mutex is a robust mutex and the previous owning thread terminated while holding the mutex lock. the mutex lock shall be acquired by the calling thread and it's up to the new owner to make the state consistent (see pthread_mutex_lock()). yeah it's the same drama as above, she's listed twice, she's just that girl ✨.

also super important: these functions shall not return an error code of [EINTR]. not gonna happen, don't even ask.

and btw, everything from here down? the following sections are informative. so like, they're context, not the law 📜.

---

⭐ EXAMPLES ⭐

None. (we're keeping it mysterious, iykyk 💜)

---

🌈 APPLICATION USAGE 🌈

None. (no notes, perfect as she is 🎀)

---

👑 RATIONALE 👑

None. (the reasoning is lost to time, we simply accept it ✨)

---

🧚 FUTURE DIRECTIONS 🧚

None. (she stays exactly like this forever, no cap)

---

💖 SEE ALSO 💖

• pthread_mutex_destroy()
• pthread_mutex_lock()
• pthread_mutex_timedlock()

and from The Base Definitions volume of POSIX.1‐2017: <pthread.h> 🦋

---

📜 COPYRIGHT 📜

okay so legally speaking, bestie, i have to tell you this exactly:

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 .

---

and that's the whole page, bestie 💜 this one came from IEEE/The Open Group, dated 2017, and she answers to the name PTHREAD...CEILING(3POSIX). go forth and ceiling your mutexes responsibly, mwah 🫶✨