Threads - Why Can't You Just Play Nicely With Your Memory_
0 likes380 views
The document discusses parallelism and multi-core processors. It notes that pre-emptive operating systems provide an illusion of parallel processes even on single-core hardware through context switching. When moving to multi-core, caches may be shared between cores on the same chip but not between chips. Communication is faster on-chip than off-chip. Shared memory requires software strategies like mutual exclusion and non-blocking algorithms to ensure reasonable behavior. Locks and memory barriers like synchronized in Java are used to prevent reading stale data. Compare-and-swap is an algorithm that allows non-blocking updates to shared memory locations.
Threads - Why Can't You Just Play Nicely With Your Memory_
- 1. Threads - Why Can't You Just Play Nicely With Your Memory? many cores with java session three two cores copyright 2013 Robert Burrell Donkin robertburrelldonkin.name
- 2. Pre-emptive multi-tasking operating systems use involuntary context switching to provide the illusion of parallel processes even when the hardware supports only a single thread of execution. Take Away from Session One
- 3. Even on a single core, there's no escaping parallelism. Take Away from Session Two
- 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. 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. 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. 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. 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. Reading Stale Data ● Recall ○ that caches are not always coherent ○ two cores and main memory may not agree about a value 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. ● Several ways to implement in hardware ● When writing a value: ○ send expected existing value ○ return actual existing value on failure ● A step along the road to transactional memory ○ Similar to optimistic locking in an RDBMS CAS - Compare and Swap
- 11. Take Away Code executing on different cores uses copies held in registers and caches, so memory shared is likely to be incoherent unless the program plays by the rules of the software platform.