Understanding RCU implementation

On 1: it is necessary to distinguish between rcu critical sections those started before rcusynchronize. Without a distinguisher, rcusynchronize might be starved waiting forever. Imagine two threads A and B that take RCU locks in a following manner (starting with A thread having a lock):

• B takes lock
• A releases lock
• A takes lock again
• B releases lock

and then cycle repeats. In such a scenario each thread releases RCU lock often enough as they should so forward progress should happen; yet RCU lock is taken at all times. Synchronize obviously needs to wait for all the locks taken before it, and phase helps with that.

On 2: that does seem to be excessive. By the time first loop exits, all preexisting critical sections are gone so any RCU readers ought to be getting updated data.

In fact I think you've lost currentphase.store(0) there? Otherwise the second loop might theoretically be starved indefinitely.

On 3: I think fence in rcureadlock is necessary to prevent possible reads from being reordered above rcurcs.store. Similarly, fence in rcusynchronize is necessary to prevent possible update writes from being reordered below rcurcs.load.