Tony Finch – blog

The other day, Paul McKenney posted an article on LiveJournal about different flavours of RCU, prompted by a question about couple of Rust RCU crates. (There are a few comments about it on LWN.)

McKenney goes on to propose an RCU classification system based on the API an implementation provides to its users. (I am curious that the criteria do not involve how RCU works.)

Here’s how I would answer the questions for QSBR in BIND:

• Are there explicit RCU read-side markers?

  No, it relies on libuv callbacks to bound the lifetime of a read-side critical section.

• Are grace periods computed automatically?

  Yes. There is an internal isc__qsbr_quiescent_state() function, but that mainly exists to separate the QSBR code from the event loop manager, and for testing purposes, not for use by higher-level code.

• Are there synchronous grace-period-wait APIs?

  No. (Because they led me astray when designing a data structure to use RCU.)

• Are there asynchronous grace-period-wait APIs?

  Yes, but instead of one-shot call_rcu(), a subsystem (such as the qp-trie code) registers a permanent callback (isc_qsbr_register()), and notifies the QSBR when there is work for the callback to do (isc_qsbr_activate()). This avoids having to allocate a thunk on every modification, and it automatically coalesces reclamation work.

• If so, are there callback-wait APIs?

  No. At the moment, final cleanup work is tied to event loop teardown.

• Are there polled grace-period-wait APIs?

  No.

• Are there multiple grace-period domains?

  One per event loop manager, and there’s only one loopmgr.