rt_mutex_proxy_unlock(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rt_mutex_proxy_unlock(9) 💅

okay bestie so you're in the Kernel API Manual rn (that's the manual name, cute right?) and this page is literally all about rt_mutex_proxy_unlock, which is a function that releases a lock on behalf of the owner. yes, on behalf. it's giving designated-driver energy. 🫶

✨ SYNOPSIS ✨

void rt_mutex_proxy_unlock (struct rt_mutex_base *lock );

that's the whole signature, no cap. returns nothing (void), takes one argument, slays, leaves. 🎀

🌸 ARGUMENTS 🌸

  • lock — the rt_mutex to be locked. yes, that's what the page says, and I'm not gonna editorialize, I'm just gonna tell you exactly what it says: the rt_mutex to be locked. 💖

🦋 DESCRIPTION 🦋

okay so first thing, and this is important: no locking. like, none. the caller has to do the serializing itself — that's on you, bestie, it's your main character responsibility. ✨

this is a special API call for PI-futex support. what it actually does is just clean up the rtmutex (debugging) state. that's it. that's the whole vibe.

and why can't you just do whatever with it concurrently? because concurrent operations on this rt_mutex are not possible — it belongs to the pi_state which is about to be freed, and it is no longer visible to other tasks. so like... nobody else can even see it. it's gone, girl. 🙈

👑 SEE ALSO 👑

kernel file ./kernel/locking/rtmutex_api.c (yes, that's where the magic lives) plus the whole friend group:

and that's the page, bestie!! 🧚 it lives in ./kernel/locking, the version is October 2026, and the page itself is literally rt_mutex_proxy_unlock(9) — which, yes, we already said at the top, but the footer said it too so I'm saying it again. iykyk 💅 💜 ⭐

📦 where this page comes from