raw_atomic_l...xchg_acquire(9)

📦 version 7.3.1, in nixpkgs unstable

💅 raw_atomic_l...xchg_acquire — a little sit-down with the Kernel API Manual ✨

okay bestie, pull up a chair 🎀 this one's from the Kernel API Manual and it's genuinely so much less scary than the name makes it look. the name is like a whole paragraph, i know 😭 but stick with me.

✨ NAME ✨

raw_atomic_long_xchg_acquire — atomic exchange, but make it acquire ordering 🦋

🌸 SYNOPSIS 🌸

long raw_atomic_long_xchg_acquire (atomic_long_t *v , long new );

that's it. that's the whole vibe check. two arguments, one lil long coming back at you 💖

🫶 ARGUMENTS 🫶

  • v — pointer to an atomic_long_t. like, this is the thing you're swapping out, the main character of the operation 👑
  • new — a long value to assign. this is what's sliding into v's spot, no questions asked ✨

🔥 DESCRIPTION 🔥

so here's the tea: it atomically updates v to new, with acquire ordering. atomically means nobody can catch it mid-swap, and acquire ordering means the memory-ordering rules are doing their thing — it's giving "i promise the reads that come after me see everything that happened before," iykyk 💅

and the important bit, ngl: it's safe to use in noinstr code. but lowkey — prefer atomic_long_xchg_acquire everywhere else. raw_ is for the special occasions, not the everyday fit 🎀

⭐ RETURN ⭐

the original value of v. like, what was there before you swapped it. the ex, basically 💀 you get them back, but they're not yours anymore.

🌈 SEE ALSO 🌈

okay this list is long long, so buckle up bestie, we're going through the whole family tree 🧚 everything here lives in the kernel file ./include/linux/atomic/atomic-long.h — iconic address, no cap:

like i said. the whole family. every single one of them slayed in their own way 💜

and that's the page, bestie 🫶 this lil beauty comes to you from ./include/linux/atomic, dated October 2026, and it's filed under raw_atomic_l...xchg_acquire(9) — go forth and swap atomically ✨💅

📦 where this page comes from