Threads - Why Can't You Just Play Nicely With Your Memory?

222 views

Published on

Many Cores with Java, Session Three: Threads - Why Can't You Just Play Nicely With Your Memory? moves on to start to think about concurrent code on two core. Some fundemental strategies are introduced briefly - non-blocking and locking.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
222
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Threads - Why Can't You Just Play Nicely With Your Memory?

  1. 1. Threads - Why Cant YouJust Play Nicely With YourMemory?many cores with javasession threetwo corescopyright 2013 Robert Burrell Donkin robertburrelldonkin.namethis work is licensed under a Creative Commons Attribution 3.0 Unported License
  2. 2. Pre-emptive multi-tasking operatingsystems use involuntary contextswitching to provide the illusion ofparallel processes even when thehardware supports only a single threadof execution.Take Away from Session One
  3. 3. Even on a single core,theres no escaping parallelism.Take Away from Session Two
  4. 4. Two Cores on One Chip● Share caches○ not L1○ perhaps L2○ probably L3● Communicate fast and fat○ in comparison to IO: very fast○ in comparison to memory: fast○ in comparison to intra-core: slow● Cache consistency is cheap(er)
  5. 5. Two Cores on Two Chip● No share caches○ not L1○ not L2○ not L3○ share only main memory● Communicate maybe...?○ in comparison to IO: fast○ in comparison to memory: so-so○ in comparison to intra-core: very slow● Consistency is expensive
  6. 6. When Memory is Shared● Until memory is shared○ compiler,○ hardware and○ operating system○ sweep the messy details under the rug● When memory is shared○ the software platform○ guarantees reasonable behaviour○ when code plays by the rules
  7. 7. Some Software Strategies● Applicable to any shared resource○ but memory as an example is■ convenient and■ common● Mutual exclusion○ no concurrent access to critical sections● Non-blocking algorithms○ CAS - compare and swap
  8. 8. Locks● Block threads○ which do not hold the lock○ from a critical section● When thread holding the lock○ exits the critical section○ other threads may no longer be blocked
  9. 9. Reading Stale Data● Recall○ that caches are not always coherent○ two cores and main memory may not agree about avalue for a memory location● Mutual exclusion is often not enough○ memory barrier needed○ hardware ensures data is coherent○ expensive● In Java, synchronized○ locks and○ issues memory barrier
  10. 10. ● Several ways to implement in hardware● When writing a value:○ send expected existing value○ return actual existing value on failure● Step along the road to transactional memory○ Similar to optimistic locking in an RDBMSCAS - Compare and Swap
  11. 11. Take AwayCode executing on different cores uses copiesheld in registers and caches, so memoryshared is likely to be incoherent unless theprogram plays by the rules of the softwareplatform.

×