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.

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
this work is licensed under a Creative Commons Attribution 3.0 Unported License

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
● 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.