PTHREAD..._GETTYPE(3POSIX)

💅 PTHREAD..._GETTYPE — ok bestie, let's talk mutex vibes

So this page lives in the POSIX Programmer's Manual (PTHREAD..._GETTYPE(3POSIX)), and before we even get into it — yes, the title has those weird ... in it, that's just how POSIX do. 🎀

---

🌸 PROLOG 🌸

Okay so first thing, no cap, 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, go consult the corresponding Linux manual page for the actual deets on Linux behavior. Or, plot twist: the interface might not even be implemented on Linux at all. 🙈 iykyk.

---

✨ NAME ✨

pthread_mutexattr_gettype, pthread_mutexattr_settype — get and set the mutex type attribute. That's it, that's the whole job. Getting and setting. Slay. 💖

---

🦋 SYNOPSIS 🦋

#include <pthread.h>

int pthread_mutexattr_gettype(const pthread_mutexattr_t *restrict attr,
    int *restrict type);
int pthread_mutexattr_settype(pthread_mutexattr_t *attr, int type);

Look at those restrict qualifiers just sitting there being all "I'm the main character." Iconic behavior honestly. ✨

---

💜 DESCRIPTION 💜

So pthread_mutexattr_gettype() and pthread_mutexattr_settype() do exactly what their names say, respectively: they shall get and shall set the mutex type attribute. That attribute lives in the type parameter you pass to these functions. And the default value of the type attribute? That's PTHREAD_MUTEX_DEFAULT. Remember that, bestie, it's important. 🫶

The type of the mutex is contained in the type attribute of the mutex attributes. The valid mutex types are literally these:

• PTHREAD_MUTEX_NORMAL
• PTHREAD_MUTEX_ERRORCHECK
• PTHREAD_MUTEX_RECURSIVE
• PTHREAD_MUTEX_DEFAULT

The mutex type affects the behavior of calls which lock and unlock the mutex. Go read pthread_mutex_lock() for the details on that, it's all there. Also: an implementation may map PTHREAD_MUTEX_DEFAULT to one of the other mutex types. So don't come for me if it's acting like one of its siblings. 😌

🚨 Behavior is undefined if the value specified by the attr argument to pthread_mutexattr_gettype() or pthread_mutexattr_settype() does not refer to an initialized mutex attributes object. Like, undefined undefined. Not "we'll figure it out" undefined. Do not test this. 🙈

---

🔥 RETURN VALUE 🔥

Upon successful completion, the pthread_mutexattr_gettype() function shall return zero and store the value of the type attribute of attr into the object referenced by the type parameter. Otherwise, an error shall be returned to indicate the error. Zero means bestie, nonzero means something's wrong.

If successful, the pthread_mutexattr_settype() function shall return zero; otherwise, an error number shall be returned to indicate the error. That's the whole system. Zero = we ate. 💅

---

💀 ERRORS 💀

The pthread_mutexattr_settype() function shall fail if:

• EINVAL — The value type is invalid.

And then, a very specific little note: these functions shall not return an error code of [EINTR]. So don't be out here checking for it. It's not coming. 🚫

The following sections are informative. (Translation: the spec says this part is the fun bonus content, not the legally-binding bit. 🌈)

---

🎀 EXAMPLES 🎀

None.

Literally none. Not one. We move. 😭

---

🧚 APPLICATION USAGE 🧚

Okay here's some genuinely important advice, listen up:

It is advised that an application should not use a PTHREAD_MUTEX_RECURSIVE mutex with condition variables — because the implicit unlock performed for a pthread_cond_timedwait() or pthread_cond_wait() may not actually release the mutex (that's what happens if it had been locked multiple times). And if that happens? No other thread can satisfy the condition of the predicate. Everyone's just stuck there. It's giving deadlock energy. Not the vibe. 🔥

---

👑 RATIONALE 👑

If an implementation detects that the value specified by the attr argument to pthread_mutexattr_gettype() or pthread_mutexattr_settype() does not refer to an initialized mutex attributes object, it is recommended that the function should fail and report an [EINVAL] error.

Note the wording bestie: recommended, not required. It's a suggestion. A little "hey, maybe do this?" from the standards committee. 🌸

---

⭐ FUTURE DIRECTIONS ⭐

None.

Nothing coming. This is the final form. Periodt. 💅

---

🌈 SEE ALSO 🌈

• pthread_cond_timedwait()
• pthread_mutex_lock()

Also, from The Base Definitions volume of POSIX.1‐2017: <pthread.h> — go check it out, the header itself is a whole mood. 🦋

---

🍓 COPYRIGHT 🍓

Okay this part is the legal bit and we keep every word of it, so here goes:

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's brought to you by IEEE/The Open Group, 2017 — the manpage name is PTHREAD..._GETTYPE(3POSIX) in case you need to cite it in your group chat later. Now go forth and set your mutex types responsibly, and please, for the love of everything, initialize your attr objects. 🫶✨