10.07.2015 Views

Is Parallel Programming Hard, And, If So, What Can You Do About It?

Is Parallel Programming Hard, And, If So, What Can You Do About It?

Is Parallel Programming Hard, And, If So, What Can You Do About It?

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

D.4. PREEMPTABLE RCU 235nextlistcall_rcu()nexttailGrace-Period State Machine Overview Thestate (recorded in rcu_try_flip_state) can takeon the following values:waitlist[0]waitlist[1]waittail[0]waittail[1]• rcu_try_flip_idle_state: the grace-periodstate machine is idle due to there being noRCU grace-period activity. The rcu_ctrlblk.completed grace-period counter is incrementedupon exit from this state, and all of the per-CPU rcu_flip_flag variables are set to rcu_flipped.donelistdonetailrcu_process_callbacks()Figure D.62: Preemptable RCU Callback Flowrcu try flip state The rcu_try_flip_statevariable tracks the current state of the grace-periodstate machine, as described in the next section.rcu try flip flag The rcu_try_flip_flag per-CPU variable alerts the corresponding CPU that thegrace-period counter has recently been incremented,and also records that CPU’s acknowledgment. Oncea given CPU has acknowledged the counter flip, allsubsequent actions taken by rcu_read_lock() onthat CPU must account for the new value of thegrace-period counter, in particular, when incrementingrcu_flipctr in rcu_read_lock().rcu mb flag The rcu_mb_flag per-CPU variablealerts the corresponding CPU that it must executea memory barrier in order for the grace-period statemachine to proceed, and also records that CPU’sacknowledgment. Once a given CPU has executedits memory barrier, the memory operations of allprior RCU read-side critical will be visible to anycodesequencedafterthecorrespondinggraceperiod.D.4.2.3 Grace-Period State MachineThis section gives an overview of the states executedby the grace-period state machine, and then walksthrough the relevant code.• rcu_try_flip_waitack_state: waiting for allCPUs to acknowledge that they have seen theprevious state’s increment, which they do bysetting their rcu_flip_flag variables to rcu_flip_seen. Once all CPUs have so acknowledged,we know that the old set of counters canno longer be incremented.• rcu_try_flip_waitzero_state: waiting forthe old counters to sum to zero. Once the counterssum to zero, all of the per-CPU rcu_mb_flag variables are set to rcu_mb_needed.• rcu_try_flip_waitmb_state: waiting for allCPUs to execute a memory-barrier instruction,whichtheysignifybysettingtheirrcu_mb_flagvariables to rcu_mb_done. Once all CPUs havedone so, all CPUs are guaranteed to see thechanges made by any RCU read-side criticalsection that started before the beginning of thecorresponding grace period, even on weakly orderedmachines.The grace period state machine cycles throughthese states sequentially, as shown in Figure D.63.Figure D.64 shows how the state machine operatesover time. The states are shown along thefigure’s left-hand side and the relevant events areshown along the timeline, with time proceeding inthe downward direction. We will elaborate on thisfigure when we validate the algorithm in a later section.In the meantime, here are some important thingsto note:1. The increment of the rcu_ctrlblk.completedcounter might be observed at different times bydifferent CPUs, as indicated by the blue oval.However, after a given CPU has acknowledgedthe increment, it is required to use the newcounter. Therefore, once all CPUs have acknowledged,the old counter can only be decremented.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!