al_lock_mutex(3)

💅 al_lock_mutex(3) 💅

Okay so real quick: this page is from the Library Functions Manual, and it’s part of the Allegro 5 API. We’re folding the manual-name vibe in right here at the top instead of doing a boring copy-paste header. Slay. ✨

---

🌸 NAME 🌸

al_lock_mutex — Allegro 5 API, bestie. That’s the whole name situation. 💖

---

🎀 SYNOPSIS 🎀

#include <allegro5/allegro.h>

void al_lock_mutex(ALLEGRO_MUTEX *mutex)

Literally exactly that. No cap. 🫶

---

🦋 DESCRIPTION 🦋

So al_lock_mutex does what it says on the tin: it acquires the lock on mutex. Iconic behavior. 💅

If the mutex is already locked by another thread, the call will block until the mutex becomes available and locked. It’s giving “waiting outside your bestie’s door while she finishes getting ready.” You’re not going anywhere until the lock is yours. 😭

Now here’s the spicy part 🔥: if the mutex is already locked by the calling thread, then the behaviour depends on whether the mutex was created with al_create_mutex(3) or al_create_mutex_recursive(3).

• In the former case — that’s al_create_mutex(3) — the behaviour is undefined. And the most likely behaviour is deadlock. So like… do not do that, bestie. That’s not the vibe. 💀
• In the latter case — al_create_mutex_recursive(3) — the count in the mutex will be incremented, and the call will return immediately. Periodt. ✨

⚠️ Warning-ish reminder: with a plain al_create_mutex(3) mutex, locking it again from the same thread is undefined behaviour, and the most likely outcome is deadlock. That’s a big yikes. Keep it clean, queen. 👑💖

---

🌈 SEE ALSO 🌈

• al_unlock_mutex(3) — the unlock bestie, obviously. 🫶

We don’t yet have al_mutex_trylock. Not yet, anyway. 🙈

---

Okay that’s the whole page, babes. Cute little sign-off: this is from the Allegro reference manual — Allegro 5 API energy — and the page is al_lock_mutex(3). No date on the footer, so I’m not inventing one. Mwah. 💋🎀🦋💜