PTHREAD_M...IOCEILING(3P)

πŸ’– PTHREAD_M...IOCEILING(3P) β€” POSIX Programmer's Manual πŸ’–

okay bestie, quick vibe check before we dive in: this page lives in the POSIX Programmer's Manual. The Linux version of this interface might act different (so like, go read the matching Linux man page for the real tea β˜•), or honestly the interface might not even be implemented on Linux at all. Not every baddie makes it to every platform, yk?


✨ PROLOG ✨

So basically β€” this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux. Periodt.


🌸 NAME 🌸

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling β€” get and set the priority ceiling of a mutex (REALTIME THREADS)


πŸŽ€ 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 πŸ’…

Okay so the pthread_mutex_getprioceiling() function shall return the current priority ceiling of the mutex. Like, it just tells you the ceiling. No drama. πŸ¦‹

Then we have pthread_mutex_setprioceiling(), and this one is doing the most. It shall attempt to lock the mutex as if by a call to pthread_mutex_lock(), EXCEPT that the process of locking the mutex need not adhere to the priority protect protocol. Sneaky? No, that's just how it's written, bestie.

On acquiring the mutex it shall change the mutex's priority ceiling and then release the mutex as if by a call to pthread_mutex_unlock(). So: grab it, glow it up, let it go. ✨

When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling. So you get the before pic AND the after pic πŸ“Έ.

If the pthread_mutex_setprioceiling() function fails, the mutex priority ceiling shall not be changed. No partial glow-ups. It's all or nothing.

🌈 RETURN VALUE 🌈

If successful, the pthread_mutex_getprioceiling() and pthread_mutex_setprioceiling() functions shall return zero. Otherwise, an error number shall be returned to indicate the error. Zero is the slay. Anything else? We're in our flop era, unfortunately. 😭


πŸ”₯ ERRORS πŸ”₯

These functions shall fail if:

  • EINVAL β€” The protocol attribute of mutex is PTHREAD_PRIO_NONE.
  • EPERM β€” The implementation requires appropriate privileges to perform the operation and the caller does not have appropriate privileges. (No invite, no entry, bestie 🚫)

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.
  • EDEADLK β€” The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current thread already owns the mutex. (Girl, you're already holding it. Let go πŸ’€)
  • 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.
  • ENOTRECOVERABLE β€” The mutex is a robust mutex and the state protected by the mutex is not recoverable.
  • 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 is up to the new owner to make the state consistent (see pthread_mutex_lock()).

The pthread_mutex_setprioceiling() function may fail if:

  • EDEADLK β€” A deadlock condition was detected.
  • EINVAL β€” The priority requested by prioceiling is out of range.
  • 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 is up to the new owner to make the state consistent (see pthread_mutex_lock()).
These functions shall not return an error code of [EINTR]. Like, don't even ask. It's not on the menu. πŸ™ˆ

The following sections are informative. (Read: cute bonus content, not the binding lore πŸ’–)


🧚 EXAMPLES 🧚

None.


πŸ“ APPLICATION USAGE πŸ“

None.


πŸ’œ RATIONALE πŸ’œ

None.


⭐ FUTURE DIRECTIONS ⭐

None.


πŸ‘‘ SEE ALSO πŸ‘‘

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

The Base Definitions volume of POSIX.1‐2017, <pthread.h>


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 🫢 go forth and ceiling those priorities ✨

mwah πŸ’‹ β€” this one's brought to you by IEEE/The Open Group, dated 2017, and it's the PTHREAD_M...IOCEILING(3P) page, xoxo πŸŽ€

πŸ“¦ where this page comes from