synchronize_srcu(9)

💅 synchronize_srcu(9) — like, the Kernel API Manual but make it make sense 🎀

okay bestie, so this is synchronize_srcu(9) from the Kernel API Manual, and honestly? it's kind of iconic. it's a wait function. a "girl, hold on, let the readers finish" function. let's get into it ✨

---

🌸 NAME 🌸

synchronize_srcu — wait for prior SRCU read-side critical-section completion 💖

like literally, it's the "wait for everyone who was reading before you to be done" function. no cap.

---

🦋 SYNOPSIS 🦋

void synchronize_srcu (struct srcu_struct *ssp );

that's it. that's the whole signature. one argument. clean. minimal. main character energy 👑

---

🎀 ARGUMENTS 🎀

• ssp — the srcu_struct with which to synchronize. that's the one you're syncing against, bestie. no substitute, no swapsies.

---

✨ DESCRIPTION ✨

so here's the tea ☕ — synchronize_srcu waits for the count to drain to zero of both indexes. both. like it's not playing favorites.

and because we don't want synchronize_srcu to get starved (rude), it does this cute little two-step: first it waits for the count of the index

index=!(ssp->srcu_ctrp - ssp->sda->srcu_ctrs[0])

to drain to zero, and then it flips the ->srcu_ctrp and waits for the count of the other index. flip it, wait, slay. 🔥

this one can block, so it must be called from process context. like, it needs a real context to nap in, okay? 😴

⚠️ BIG WARNING, do not skip this one: it is illegal to call synchronize_srcu from the corresponding SRCU read-side critical section. like, doing so will result in deadlock. fr fr. deadlock. we don't do that here. 💀

however (and this is the fun part), it is perfectly legal to call synchronize_srcu on one srcu_struct from some other srcu_struct's read-side critical section — as long as the resulting graph of srcu_structs is acyclic. yes bestie, we're doing graph theory now. acyclic or it's a no from me. 🧚

💜 the memory-ordering guarantees (the juicy part)

there are memory-ordering constraints implied by synchronize_srcu. on systems with more than one CPU, when synchronize_srcu returns, each CPU is guaranteed to have executed a full memory barrier since the end of its last corresponding SRCU read-side critical section whose beginning preceded the call to synchronize_srcu. 🫶

in addition, each CPU having an SRCU read-side critical section that extends beyond the return from synchronize_srcu is guaranteed to have executed a full memory barrier after the beginning of synchronize_srcu and before the beginning of that SRCU read-side critical section.

and note — these guarantees include CPUs that are offline, idle, or executing in user mode, as well as CPUs that are executing in the kernel. yes, even the sleeping ones. everyone gets a barrier. 🌈

⭐ and if CPU A and CPU B are involved…

furthermore, if CPU A invoked synchronize_srcu, 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_srcu. 💅

this guarantee applies even if CPU A and CPU B are the same CPU — but again, only if the system has more than one CPU. iykyk.

🍓 the fine print (still important, still cute)

of course, these memory-ordering guarantees apply only when synchronize_srcu, srcu_read_lock, and srcu_read_unlock are passed the same srcu_struct structure. same struct energy or it doesn't count. 🙈

implementation of these memory-ordering guarantees is similar to that of synchronize_rcu.

🌸 the idleness heuristic moment

if SRCU is likely idle as determined by srcu_should_expedite, expedite the first request. ⚡

this semantic was provided by Classic SRCU, and is relied upon by its users, so TREE SRCU must also provide it. (respect the legacy, bestie. it ate.) 👑

🫶 note that detecting idleness is heuristic and subject to both false positives and negatives. so like… it's vibes-based. it's doing its best.

---

🦋 SEE ALSO 🦋

so many icons in one family tree, let me list them 💖

• Kernel file ./kernel/rcu/srcutree.c
• init_srcu_struct_generic(9)
• init_srcu_struct_fast(9)
• init_srcu_struct_fast_updown(9)
• cleanup_srcu_struct(9)
• call_srcu(9)
• synchronize_srcu_expedited(9)
• get_state_synchronize_srcu(9)
• start_poll_synchronize_srcu(9)
• poll_state_synchronize_srcu(9)
• srcu_barrier(9)
• srcu_expedite_current(9)
• srcu_batches_completed(9)

---

and that's the whole page!! 🎀 biggest hugs to the ./kernel/rcu source and this October 2026 version stamp — she's dated, she's documented, she's done. go forth and synchronize responsibly, bestie 💜🦋✨