1 / 19

Summary of Boehm’s “threads … as a library” + other thoughts and class discussions

Summary of Boehm’s “threads … as a library” + other thoughts and class discussions. CS 5966, Feb 4, 2009, Week 4. Assignment : Dining Phil code . Some versions of Dining Phil have data races What are races? Why are they harmful? Are they always harmful? P1 : temp = shared-x P2 : x = 1

nemo
Download Presentation

Summary of Boehm’s “threads … as a library” + other thoughts and class discussions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Summary of Boehm’s“threads … as a library”+ other thoughts and class discussions CS 5966, Feb 4, 2009, Week 4

  2. Assignment : Dining Phil code • Some versions of Dining Phil have data races • What are races? • Why are they harmful? • Are they always harmful? • P1 : temp = shared-x • P2 : x = 1 • versus • the same codes inside a single lock/unlock • In this case, the atomicity of the locations gives the same computational semantics • Be sure of the atomicity being assumed!

  3. Why we should know memory models • Not very intuitive • Takes time to sink in • Something as important as this stays with one only through repeated exposures • Other classes do not give emphasis • They attempt to sweep things under the rug • They are playing ‘head in the sand’! • While it is like a grain of sand, its presence under the eye-lid or in a ball-bearing is what mem models are akin to… • This is dangerous! • Stifles understanding • We are in a world where even basic rules are being broken • Academia is about not buying into decrees • e.g. “goto”s always harmful?

  4. Why we should know memory models • Clearly, success in multi-core programming depends on having high-level primitives • Unfortunately nobody has a clue as to which high level primitives “work” • are safe and predictable • are efficient • Offering an inefficient high-level primitive does more damage • People will swing clear back to a much lower primitive!

  5. Why we should know memory models • Till we form a good shared understanding of which high level primitives work well, we must be prepared to evaluate the low level effects of existing high level primitives • The added surprises that compilers throw in can cause such non-intuitive outcomes that we had better know that they exist, and solve issues when they arise

  6. Why we should know memory models • Locks are expensive • Performance and energy • If lock-free code works superbly faster, and there is an alternate (lock-free) reasoning to explain such behaviors, clearly one must entertain such thoughts • Need all tools in one’s kit • HW costs are becoming very skewed • Attend Uri Weiser’s talk Feb 12th • Finally, we need to understand what tools such as Inspect are actually doing!

  7. Where mem models mattered • PCI bus ordering (producer/consumer broken) • Holzmann’s experience in multi-core SPIN • Our class experiments • OpenMPmem model in conflict with Gccmem model • In understanding architectural consequences • Hit-under-miss optimization in speculative execution (in snoopy busses such as HP Runway)

  8. On “HW / SW” split • Till the dust settles (if at all) in multi-core computing, you had better be interested in HW and SW matters • HW matters • C-like low level behavior matters • Later we will learn whether “comfortable” abstractions such as C# / Java are viable • Of course when programming in the large, we will prefer such high level views; when understanding concepts, however, we need all the “nuts and bolts” exposed…

  9. Boehm’s points • Threads are going to be increasingly used • We focus on languages such as C/C++ where threads are not built into the language – but are provided through add-on libraries • Ability to program in C/Pthreads comes through ‘painful experience’ – not through strict adherence to standards • This paper is an attempt to ameliorate that

  10. Page 2: Thread lib, lang, compiler … • Thread semantics cannot be argued purely within the context of the libraries • They involve the • compiler semantics • language semantics (together the “software” or “language” mem model) • Disciplined use of concurrency thru thread APIs is OK for 98% of the users • But need to know the 2% uses outside .. esp in a world where we rely on MP systems for performance

  11. P2 S3: Pthread Approach to Concur. • Seq consistency is the intuitive model • Too expensive to implement as such • x = 1 ; r1 = y; • y = 1 ; r2 = x; • final value of x=y=0 is allowed (and is what happens today) • Compilers may reorder subject to intra-thread dependencies • HW may reorder subject to intra-thread dependencies

  12. P2 S3: Pthread silent on mem model semantics ; reasons: • Many don’t understand • So they preferred “simple rules” • Instead, it “decrees” : • Synchronize thread execution using mutex_lock , mutex_unlock • then it is expected that no two threads race on a single location • (Java is more precise even about racing semantics)

  13. P2 S3: Pthread silent on mem model semantics ; reasons: • In practice, mutex_lock etc contain memory barries (fences) that prevent HW reordering around the call • Calls to mutex_lock etc treated as opaque function calls • No instructions can be moved across • If f() calls mutex_lock(), even f() is treated as such • Unfortunately, many real systems intentionally or unknowingly violate these rules

  14. P4 S4: Correctness Issues • Consider this program • if (x==1) ++y; • if (y==1) ++x; • Is (x==1, y==1) acceptable? Is there a race? • Not under SC! • However if the compiler transforms the code to • ++y ; if (x != 1) –y; • ++x ; if (y != 1) –x; • then there is a race / x==1, y==1 is allowed… is a possible conclusion (or say the semantics are undefined)

  15. P5 S4.2 Rewriting of adjacent data • Bugs of this type actually have arisen • struct (int a:17, int b:15} x • Now realise “x.a=42” as • {tmp =x; tmp &= ~0x1fff; tmp |= 42; x=tmp; } • Introduces an “unintended” write of b also! • OK for sequential • But in concurrent setting, a concurrent “b” update could now race !! • Race is not “seen” at source level!

  16. P5 : another example • struct {char a; char b; … char h; } x • x.b = ‘b’; x.c=‘c’; … ; x.h = ‘h’; can be realized as • x = ‘hgfedcb\0’ | x.a • Now if you protect “a” with one lock and “b thru h” with another lock” , you are hosed – there is a data race! • C should define when adjacent data may be over-written

  17. P5/P6 : register promotion • Compilers must be aware of existence of threads • Consider the code optimized to speed up for serial case • for(..){ • if (mt) lock(…); • x = ..x… • if (mt) unlock(..); • }

  18. P5/P6 : register promotion • for(..){ • if (mt) lock(…); • x = ..x… • if (mt) unlock(..); } • can be optimized according to Pthread rules to • r=x; for(…) {.. • if (mt) { x=r; lock(…); r=x; } • r = …x…; • if (mt) { x=r; unlock(..); r=x; } } • x=r; • Fully broken – reads/writes to x without holding lock!

  19. avoiding expensive synch. • for(mp = start; mp<10^4; ++mp) • if (!get(mp)) { • for (mult=mp; mult<10^8; mult +=mp) • if (!get(mult)) set(mult) • Sieve algo • Benefits from races !!

More Related