This preview shows page 1. Sign up to view the full content.
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 diﬀerent 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 buﬀers 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 oﬃce 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 diﬀerent tasks seeing diﬀerent 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 diﬀerent 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 deﬁniCons… – 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 ﬁx it!” – How much parallel performance are you willing to sacriﬁce? – 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
- Winter '09