synchronize_rcu(9)

📦 version 7.3.1, in nixpkgs unstable

✨ synchronize_rcu(9) ✨

okay bestie, gather round, because this is a kernel API manual page (synchronize_rcu, section 9 of the Kernel API Manual) and it's honestly kind of a big deal 💅

🎀 NAME 🎀

synchronize_rcu — literally just wait until a grace period has elapsed, no biggie 🦋

🌸 SYNOPSIS 🌸

void synchronize_rcu (void );

🫶 ARGUMENTS 🫶

  • void — no arguments. that's it. nothing. zero. the void is the vibe 💀

🔥 DESCRIPTION 🔥

so here's the tea: control is gonna come back to you, the caller, some time after a full grace period has elapsed. in other words? after all the RCU read-side critical sections that are currently executing have completed. slay. ✨

but bestie, listen — upon return from synchronize_rcu, you might very well be executing concurrently with new RCU read-side critical sections that began while synchronize_rcu was waiting. so like, don't get it twisted 🙈

RCU read-side critical sections are delimited by rcu_read_lock and rcu_read_unlock, and they can be nested, no cap. plus — and this is only in v5.0 and later — regions of code across which interrupts, preemption, or softirqs have been disabled also serve as RCU read-side critical sections. that includes hardware interrupt handlers, softirq handlers, and NMI handlers. iconic behavior honestly 👑

now, this guarantee implies further memory-ordering guarantees, and this part is important so pay attention 🔥:

  • on systems with more than one CPU, when synchronize_rcu returns, each CPU is guaranteed to have executed a full memory barrier since the end of its last RCU read-side critical section whose beginning preceded the call to synchronize_rcu.
  • in addition, each CPU having an RCU read-side critical section that extends beyond the return from synchronize_rcu is guaranteed to have executed a full memory barrier after the beginning of synchronize_rcu and before the beginning of that RCU read-side critical section.
  • and note that these guarantees include CPUs that are offline, idle, or executing in user mode, as well as CPUs that are executing in the kernel. offline CPUs are still getting their memory barriers, they're just doing it from the couch 🛋️

furthermore — if CPU A invoked synchronize_rcu, which returned to its caller on CPU B, then both CPU A and CPU B are guaranteed to have executed a full memory barrier during the execution of synchronize_rcu — even if CPU A and CPU B are the same CPU (but again, only if the system has more than one CPU). yes, even then. especially then. 🧚

implementation of these memory-ordering guarantees is described here: Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst. go read it, iykyk 📚

💜 SEE ALSO 💜

kernel file ./kernel/rcu/tree.c — and honestly the whole friend group is here:

okay that's the whole page bestie, you ate that 💖 and for the credits moment: this little icon lives in ./kernel/rcu, dated October 2026, and it's the synchronize_rcu(9) page — no cap, that's the whole sign-off 🎀✨ 🌈

📦 where this page comes from