call_rcu_tasks(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 NAME 🌸

call_rcu_tasks(9) β€” from the Kernel API Manual, bestie β€” Queue an RCU for invocation task-based grace period. πŸ’…

✨ SYNOPSIS ✨

void call_rcu_tasks (struct rcu_head *rhp , rcu_callback_t func );

πŸŽ€ ARGUMENTS πŸŽ€

  • rhp β€” structure to be used for queueing the RCU updates. 🫢
  • func β€” actual callback function to be invoked after the grace period. 🌟

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so here's the tea: the callback function will be invoked some time after a full grace period elapses β€” in other words, after all currently executing rcu-tasks read-side critical sections have completed. ✨

call_rcu_tasks assumes that those read-side critical sections end at a voluntary context switch (not a preemption!), at cond_resched_tasks_rcu_qs, at entry into idle, or at transition to usermode execution. periodt. πŸ’…

Because of that, there are no read-side primitives analogous to rcu_read_lock and rcu_read_unlock β€” none, zero, not a one πŸ’€ β€” because this primitive is intended to determine that all tasks have passed through a safe state, not so much for data-structure synchronization. It's giving "safe-state detector," not "data-structure-sync main character." 🫢

See the description of call_rcu for more detailed information on memory ordering guarantees. iykyk πŸ”₯

🌈 SEE ALSO 🌈


mwah πŸ’‹ source/version: ./kernel/rcu Β· date: October 2026 Β· page: call_rcu_tasks(9) β€” bye bestie, go queue that callback responsibly! πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from