Concurrency and Memory Models Filip Sieczkowski Why concurrency? - - PowerPoint PPT Presentation

▶

Nov 28, 2022 173 likes •375 views

Concurrency and Memory Models Filip Sieczkowski Why concurrency? Moores law Every two years, the number of transistors in a dense integrated circuit doubles The keystone of microprocessor industry Physical limitations Finite

SLIDE 1

Concurrency and Memory Models

Filip Sieczkowski

SLIDE 2

Why concurrency?

SLIDE 3

Moore’s law

Every two years, the number of transistors in a

dense integrated circuit doubles

The keystone of microprocessor industry

SLIDE 4

Physical limitations

Finite speed of light
Atomic nature of matter
Power consumption & heat dissipation

SLIDE 5

Resolution: concurrency

Instead of increasing speed, increase the number
f processors
Not necessarily the only way, see Matt Might:

http://matt.might.net/papers/might2009manycorefad-talk.pdf

Need to run things on multiple chips and

communicate

SLIDE 6

Shared-memory Concurrency Primer

SLIDE 7

Modelling Concurrency

SLIDE 8

Interleaving Interpretation

Any thread can execute an

atomic command

The effect takes place directly

in the memory

Corresponds to any sequential

interleaving of the instructions

In the example, possible

results are (0, 1), (1, 0) and (1,1)

SLIDE 9

Libraries for Concurrency

Writing correct concurrent code is very tricky
Most languages provide libraries, like

java.util.concurrent

Even using libraries and locks requires care

SLIDE 10

Fine-grained Concurrency:  a spin-lock

Locks allow ownership to just
ne thread at a time
We need an atomic

communication primitive!

Compare-and-swap is costly
Even the simplest algorithms

are very complicated

SLIDE 11

Relaxed Memory pt. 1 Total Store Order

SLIDE 12

What about Performance?

The standard model for concurrency is slow
Memory is huge and located far away:

writing costs 10–20 cycles at the least!

Undermines the reason for adding concurrency

SLIDE 13

Relaxed Memory: TSO

Each thread is equipped with

a FIFO buffer

A write action is queued in the

buffer

The thread tries to read from

its own store buffer before consulting the main memory

The buffered writes are

nondeterministically flushed

SLIDE 14

Weak Behaviours on TSO

SLIDE 15

Managing the Store-buffers

Fences ensure the buffered writes get committed to

main memory

This allows to regain SC behaviours, but at a cost
Compare-and-swap also needs to flush the

buffered writes to main memory

Presence of relaxed memory complicates

reasoning even further!

SLIDE 16

Relaxed Memory pt. 2 Even More Relaxed

SLIDE 17

TSO as Code Reordering

We can think of the store

buffer effects as executing the reads before the writes

But why stop there?

SLIDE 18

Message Passing  and Relaxed Memory

In sequentially consistent

semantics r is always 42

This is also the case on TSO!
What happens if we allow

more code reordering?

Power and ARM processors

actually allow that to happen!

SLIDE 19

Memory Models  and Compilers

Need to produce efficient code
Necessary to exploit relaxed behaviours of

machines — without sacrificing correctness

Some languages (Java, C/C++) also have

nonstandard memory models on the source level!

SLIDE 20

Recap

Concurrency is here to stay
It’s hard to use properly
The actual machine architectures are even more

complex

Compiler writers need to exploit these behaviours