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

328 APPENDIX F. ANSWERS TO QUICK QUIZZESif:: i == 0 -> a = -1;:: else -> a = -2;fi;could be modeled as something like:EXECUTE_MAINLINE(stmt1,if:: i == 0 -> goto stmt1_then;:: else -> goto stmt1_else;fi)stmt1_then: skip;EXECUTE_MAINLINE(stmt1_then1, a = -1; goto stmt1_end)stmt1_else: skip;EXECUTE_MAINLINE(stmt1_then1, a = -2)stmt1_end: skip;However, it is not clear that the macro is helpingmuch in the case of the “if” statement, so these sortsof situations will be open-coded in the following sections.Quick Quiz E.16:Why are lines 45 and 46 (the in_dyntick_irq=0;and the i++;) executed atomically?Answer:These lines of code pertain to controlling the model,not to the code being modeled, so there is no reasonto model them non-atomically. The motivation formodeling them atomically is to reduce the size ofthe state space.Quick Quiz E.17:What property of interrupts is this dynticks_irq()process unable to model?Answer:One such property is nested interrupts, which arehandled in the following section.Quick Quiz E.18:Does Paul always write his code in this painfullyincremental manner???Answer:Not always, but more and more frequently. In thiscase, Paul started with the smallest slice of codethat included an interrupt handler, because he wasnot sure how best to model interrupts in Promela.Once he got that working, he added other features.(But if he was doing it again, he would start witha “toy” handler. For example, he might have thehandler increment a variable twice and have themainline code verify that the value was alwayseven.)Why the incremental approach? Consider the following,attributed to Brian W. Kernighan:Debugging is twice as hard as writing thecode in the first place. Therefore, if youwrite the code as cleverly as possible, youare, by definition, not smart enough to debugit.This means that any attempt to optimize the productionof code should place at least 66% of its emphasison optimizing the debugging process, even atthe expense of increasing the time and effort spentcoding. Incremental coding and testing is one wayto optimize the debugging process, at the expenseof some increase in coding effort. Paul uses this approachbecause he rarely has the luxury of devotingfull days (let alone weeks) to coding and debugging.Quick Quiz E.19:But what happens if an NMI handler starts runningbefore an irq handler completes, and if that NMIhandler continues running until a second irq handlerstarts?Answer:This cannot happen within the confines of a singleCPU. The first irq handler cannot complete untilthe NMI handler returns. Therefore, if each of thedynticks and dynticks_nmi variables have takenon an even value during a given time interval, thecorresponding CPU really was in a quiescent stateat some time during that interval.Quick Quiz E.20:This is still pretty complicated. Why not just havea cpumask_t that has a bit set for each CPU that isin dyntick-idle mode, clearing the bit when enteringan irq or NMI handler, and setting it upon exit?Answer:Although this approach would be functionallycorrect, it would result in excessive irq entry/exitoverhead on large machines. In contrast, theapproach laid out in this section allows each CPUto touch only per-CPU data on irq and NMIentry/exit, resulting in much lower irq entry/exitoverhead, especially on large machines.