Ally x 0 y 0 task 1 task 2 reg1 x reg2 y y

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ve) Ini!ally, x == 0, y == 0 Task 1 Task 2 reg1 = x reg2 = y y = 1 x = 2 What about reg1 = 2, reg2 = 1 ? The “blame the hardware” explana3on: •  Processors typically don’t serialize memory ops (parCcularly on large-­‐scale machines) •  In pracCce, independent memory ops can have different latencies / be reordered in HW •  analogous to compiler situaCon: HW doesn’t know about all other tasks y Task 1 reg1 = x y = 1 In shared memory, write buffers can introduce similar reorderings as the network did here memory c c c socket node CSEP 524: Parallel ComputaCon c memory c Winter 2013: Chamberlain x c c socket node c Task 2 reg2 = y x = 2 40 Clarifying the “Inconsistency” in MCMs [Here is something I stumbled over in lecture and got help clarifying at the happy office hour. Hopefully I’ve got them right now (he wrote at 12pm)]: •  As stated in lecture, MCMs are about whether or not two tasks have a consistent view of what happened •  In class, I was having trouble connecCng the dots between the surprising reorderings as explained and different tasks seeing different things. Try this: –  pretend you’re task 1 (or the programmer who wrote it) –  you know that according to your program order, you are loading x and then storing y; and that task 2 is loading y then storing x –  upon gexng the value of 2 for x, you reason that “Oh, task 2 must have run before me since I saw the updated x value” –  meanwhile, task 2 does the symmetric thing: “Oh, task 1 must have run before me since I saw the updated y value” –  the fact that we each conclude different orderings based on our observaCons suggests that our view of what happened w.r.t. memory is inconsistent CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 41 Relaxed/Weak Consistency Models •  Without gexng into detailed definiCons… –  much less intuiCve than strict/sequenCal consistency –  but much more likely to be implemented/adopted in pracCce •  Several other models exist as well (beyond the scope of this course) CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 42 Possible Aatudes About MCMs “Memory what?” –  Goal for this class: Get you beyond this point; make you aware of this important and complex topic “It’s dumb that we are living with this—let’s fix it!” –  How much parallel performance are you willing to sacrifice? –  How much work to make compilers, architectures conform? “This is complicated, I don’t want to think about it!” –  Completely natural, but accept that this is part of life… –  As a parallel programmer, you ignore it at your peril “I’ll just write code without data races, so I’m good” –  True enough, if you can sCck to that CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 43 MCMs and Data Races data races: –  Uncoordinated accesses to shared memory by disCnct tasks like we’ve been talking about here –  several memops to same locaCon where 1 or more is a wr...
View Full Document

This document was uploaded on 04/04/2014.

Ask a homework question - tutors are online