1. Information-Flow Models for Shared Memory Allon Adir Hagit Attiya Gil Shurek

2. Final state: R2=2 ? Prog 1 Prog 2 load(X, R1)load(Y, R3) R2 := R1R3 := R3 + 1 R1 := 1 store(R1, Y)store(R3, X) Initial state: All=0 Program Example

3. Prog 1 Prog 2 load(X, R1)load(Y, R3) R2 := R1R3 := R3 + 1 R1 := 1 store(R1, Y)store(R3, X) Initial state: All=0 Final state: Y=R1=1, X=R2=R3=2 Program Example

4. Final state: Y=R1=1, X=R2=R3=2 Prog 1 Prog 2 load(X, R1)load(Y, R3) R2 := R1R3 := R3 + 1 R1 := 1 store(R1, Y)store(R3, X) Initial state: All=0 PowerPC Consistency

5. Shared-Memory Semantics Capturing intricate shared-memory behaviors:  Speculation  Out-of-Order Execution  Synchronization  Granularity of Memory Accesses Without revealing micro-architecture details

6. Outline  What is an Architecture?  What is a Computation Model?  The Framework  Sequential Consistency  PowerPC Consistency

7. What is an "Architecture"?

8. Elements of an Architecture  Resources  Granules  States  Instructions  Formats  Operands  Source/Target  Addressing-Mode  State Transformation

9. Elements of an Architecture  Program order

10. Computation Model  Can we reach final state s 2 by running a program Prog from initial state s 1 ? Written as  Is  s 1, s 2, Prog  possible?

11. Prog 1 Prog 2 store(R2, X) R1:=1 R2:=2 store(R1, X)store(R2, X) Initial state: R1=R2=X=0 Final state: R1=1, R2=2, X=0 X=1 X=2 Example: Sequential Consistency

12. load store mul xor load Text Order nand branch cmp  Instruction instances + Text order  Flow-of-Information Is the flow-of-information allowed by the model? The Framework

13.  Resource X,R  Assignment resource-value pair (X,5)  Operation in-out pair ({(X,5)},{(R,5)})  Instruction ({(X,0)},{(R,0)}), ({(X,1)},{(R,1)}),...  Program sequence of commands C 1,...,C m  Commandan instruction B and a function next: B  [1..m]  {  } The Elements

14. Program Order: Example C 1 : load(X,R1) C 2 : R3 := R1+R2 next(C 1 )=2 next(C 2 )=  op 1 : ({(X,1)},{(R1,1)}) op 2 : ({(R1,1),(R2,1)}, {(R3,2)}) s 1 : {(X,1), (R1,1), (R2,1), (R3,1)} s 2 : {(X,1), (R1,1), (R2,1), (R3,2)} Prog Instantiating Prog Program order: s 1  op 1  op 2  s 2

15. Reads-From Mapping  s 1 : All=1 load(X,R1) R3 := R1+R2 s 2 : R3=2, others=1 R1 R2

16. Reads-From Mapping  s 1 : All=1 load(X,R1) R3 := R1+R2 s 2 : R3=2, others=1 R1 R2 R1 R2, X R3

17. store(R2,X) store(R1,Y) s 1 : All=0 s 2 : All=1 load(X,R1) load(Y,R2) The Reads-From Mapping is not Cyclic

18. View orders   Order the operations in Prog  One for each Prog i  Obey architecture-specific rules relating program-order reads-from mapping

19. I(X) s1s1 op 3 s2s2 op 4 op 2 op 1 op 5 < < < <  (x) O(X) Sequential Execution Information can not be read from the hidden past

20. s1s1 op 3 s2s2 op 4 op 2 op 1 < < < <  Sequential Execution Information can not be read from the future op 5 Relative to which order?

21. Sequential Consistency  S 1,S 2,Prog  is sequentially consistent if  Prog can be instantiated with a set of operations A and program order  A single view order  linear  extends the program order  Information flow satisfies the sequential execution conditions relative to view order

22. PowerPC Consistency Information flow satisfies the sequential execution conditions  Relative to program order  Relative to view orders

23. View orders enforce that  Memory is coherent, except for local stores.  Shared resource dependencies are preserved.  sync orders operations around it.  sync is transitive (sort of…).  Branch dependencies are preserved. PowerPC Consistency: View Orders

24. PowerPC Consistency: View Orders I

25. PowerPC Consistency: View Orders II

26. Speculation is Visible to Programs Final state: X=Y=1 R1=1,R2=0 R3=1,R4=0 Initial state: All=0 Prog 1 Prog 2 Prog 3 Prog 4 load(X,R1)load(Y,R3)store(1,X)store(1,Y) sync load(Y,R2)load(X,R4)