G if the locks are determined by dynamic values var a

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: deadlock –  yet this is not a foolproof soluCon… CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 18 Problems with Taking Locks in Sorted Order 1) SomeCmes you can’t predict the locks you’ll need –  e.g., if the locks are determined by dynamic values var A$: [1..numItems] sync real =0.0;// synchronized data array const i = infile.read(int); // read an unknown index const val = A$[i]; // grab its value & lock const j = someBigComputation(val); const val2 = A$[j]; // compute some other index // grab its value & lock A$[j] = val; A$[i] = val2; // swap the values, // ...releasing the locks /* If we can’t determine the relative ordering of i and j a priori, we can’t rely on this code to be safe */ CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 19 Problems with Taking Locks in Sorted Order 2) SomeCmes you may not realize what locks you’re taking –  e.g., if you’re calling into library code that takes locks •  a good library would presumably document such behavior •  but will users think deeply enough to take such issues into account? •  arguably the issue interferes with the black box benefit of libraries CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 20 Wri3ng Deadlock-­‐Free Lock Code 3) Use atomic operaCons Concept: –  never block –  instead, ensure no other task can see intermediate state •  analogy to databases… we’ll come back to this later… CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 21 PiYalls of Using Locks III (and of Shared Memory Parallelism more generally) •  Memory consistency model impacts? –  a problem with library-­‐based locks in tradiConally sequenCal languages •  e.g., C+Pthreads, as documented in Boehm paper –  even in designed-­‐to-­‐be-­‐parallel languages, something to be wary of •  e.g., Java, C#, Chapel, etc. (Note: C/C++ are evolving to address this by becoming parallel-­‐aware) CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 22 Memory Consistency Models (“MCMs”) Memory Consistency Models in a Nutshell Memory Consistency Model: CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 24 Memory Consistency Models in a Nutshell Memory Consistency Model: Rules that define how disCnct tasks may view concurrent updates to memory. CSEP 524: Parallel ComputaCon Winter 2013: Chamberlain 25 Strict Consistency •  All reads/writes to memory are viewed in a globally consistent order by all tasks –  i.e., intuiCvely, exactly what you would like –  e.g., imagine all memory ops went over a single wire or were guarded by a single lock –  by definiCon, different tasks couldn’t have simultaneous contradictory noCons of memory –  but, pracCcally speaking, this is untenable •  kills parallelism across tasks by making memory a boLleneck •  also, destroys architectural benefits of mulCple memory banks •  i.e., it could be done, but not without sacrificing performance...
View Full Document

This document was uploaded on 04/04/2014.

Ask a homework question - tutors are online