LAWS OF ORDER: EXPENSIVE SYNCHRONIZATION IN CONCURRENT ALGORITHMS CANNOT BE ELIMINATED

1

Martin Vechev IBM T.J. Watson Research Center

Joint work with: Hagit Attiya, Rachid Guerraoui, Danny Hendler, Petr Kuznetsov, Maged Michael

2

Concurrency

…is about synchronization

3

Synchronization

but how much ?

4

Synchronization

we don’t know

5

Synchronization

manual empirical process

6

Synchronization

time consuming

7

Synchronization

too much is inefficient

8

Synchronization

too little is incorrect

9

Example: Set ADT

bool add(int key){ ???}

bool remove(int key){ ???}

bool contains(int key){ ???}

10

Our Result

Concurrent abstract data types (stacks, queues, sets, hash tables,

counters …)

and mutual exclusion algorithms

must use expensive synchronization

11

Implications

concurrent programming:

guidance on when avoiding expensive synchronization is futile

12

“…although I hope that these shortcomings will be addressed, I hasten to add that they are insignificant compared to the huge step forward that this paper represents….”

-- Linux Weekly News, Jan 26, 2011

https://lwn.net/Articles/423994/

Implications

13

Implications

hardware design:

motivation to lower cost of specific synchronization

14

Implications

API design:

API specification affects synchronization

15

Implications

program verification:

- declare incorrect when synchronization is missing - simplify verification under weak memory models

16

What expensive synchronization?

order: read-after-write

17

... write X read Y ...

read Ywrite X

modern architectures/languages

Read-after write

reordering

... write X fence read Y

Fence: enforce order

Example: Read-after-Write

18

What expensive synchronization?

atomicity: atomic write-after-read

Atomic Write-after-Read

... read X write Y ...

... read X write X ...

Examples:compare-and-swapfetch-and-addread-modify-write

20

Which abstract data types ?

Atomicity

DeterminismCommutativity

21

Example: Set ADT

bool add(v) add v bool remove(v) remove v bool contains(v) check if v is in the set

22

Example: Set ADT

Example Histories:

add(5): true; remove(5): true; … add(5): true; add(5): false; … add(5): true; contains(5): true; …

23

specification of Set is deterministic

Example: Set ADT

24

commutativity: a way to select methods

25

select non-commutative methods

26

method A is non-commutative if there exists another method B where:

A influences Band

B influences A

27

bool add(v) is non-commutative:

Example: Set ADT

add(v) influences

add(v)

28

Example: Set ADT

{} add(5): true; add(5): false;

(add influences add)

29

bool remove (v) is non-commutative:

Example: Set ADT

remove (v) influences

remove(v)

30

bool contains(v) is commutative:

Example: Set ADT

contains(v) does not influence add(v), remove(v) or contains(v)

31

How about void add(v) ?

void add(v) is commutative

Example: Set ADT

nobody can influence void add(v)

32

Atomicity

DeterminismCommutativity

Which abstract data types ?

33

Linearizability

DeterminismCommutativity

Which abstract data types ?

34

Linearizability:

when a concurrent implementation

is equivalent to a sequential specification

[Herlihy&Wing – TOPLAS’90][Filipovic et. al – ESOP 2009]

35

Theorem

given: deterministic sequential

specification, non-commutative method M

then: any linearizable implementation of spec

contains sequential executions of M that use

RAW or AWAR

36

bool add(int key){ ???}

bool remove(int key){ ???}

bool contains(int key){ ???}

Example: Set ADT

37

Set specification is deterministic

bool remove(v) is non-commutative

Any linearizable implementation of remove (v) must have sequential

executions with RAW or AWAR

Example: Set ADT

38

bool add(int key){ ???}

bool remove(int key){ RAW or AWAR}

bool contains(int key){ ???}

Example: Set ADT

39

Set specification is deterministic

bool contains(v) is commutative

cannot say anything about contains(v)

Example: Set ADT

40

bool add(int key){ ???}

bool remove(int key){ RAW or AWAR}

bool contains(int key){ ???}

Example: Set ADT

41

Set specification is deterministic

bool add(v) is non-commutative

Any linearizable implementation of add(v) must have sequential

executions with RAW or AWAR

Example: Set ADT

42

bool add(int key){ RAW or AWAR}

bool remove(int key){ RAW or AWAR}

bool contains(int key){ ???}

Example: Set ADT

43

Proof Intuition: Writing

show a method must write

otherwise, it cannot influence anyone

hence, method would be commutative

44

{}

Proof Intuition: Writing

add(5) true {}

no shared write

add(5) true

add(5) did not influence add(5)

45

Proof Intuition: Reading

show a method must read

otherwise, it cannot be influenced by anyone

hence, method would be commutative

46

Proof Intuition: RAW

{}

add(5)

trueadd(5)

true

W

no RAW

add(5) true trueadd(5)

Linearization

{}

47

Summary

Atomicity (Linearizability)

DeterminismCommutativity

RAWAWAR

48

Future Directions

Even when laws have been written down, they ought not always to remain unaltered -- Aristotle

49

Future Directions

Algorithm Specialization:

Relax dimensions to obtain new algorithms

50

Future Directions

Can the dimensions be weakened? (while keeping lower bound)

Sequential Consistency ? Weaker Commutativity ? Abstract Determinism ?

51

Future Directions

Can the result by strengthened ?

write-write read-read

sequences of reads and writes composite operations

more (all) executions

52

The End