Relaxed memory models offer suitable abstractions of the actual optimizations offered by multi-core architectures and by compilers of concurrent programming languages. Using such abstractions for verification purposes is challenging in part since they introduce yet another source of high non-determinism, thus contributing to the state explosion problem. In the last years several techniques have been proposed to mitigate those problems so to make verification under relaxed memory models feasible. In this talk I present some of those techniques and discuss if and how those techniques can be adopted in Maude or Maude-based verification tools.

1. Can we efficiently verify concurrent
programs under relaxed memory
models in Maude?
Yehia Abd Arrahman, Marina Andric,
Alessandro Beggiato, and Alberto Lluch Lafuente
WRLA 2014, 5-6 April 2014, Grenoble

2. I would say yes.
Worth investigating
Can we efficiently verify concurrent programs
under relaxed memory models in Maude?

3. SOME
MOTIVATIONS

4. x := 1;
if y == 0 then
u := 1
else
skip
y := 1;
if x == 0 then
v := 1
else
skip
A SIMPLE PROGRAM
u v
===
0 0
0 1
1 0
1 1
What are the possible outcomes for u and v?

5. x := 1;
if y == 0 then
u := 1
else
skip
y := 1;
if x == 0 then
v := 1
else
skip
A SIMPLE PROGRAM
u v
===
0 0
0 1
1 0
1 1
✓
???
✓
✓
What are the possible outcomes for u and v?
✓

6. MORE ANNOYANCES...
x := 1
Maude> search P =>* Q .
...
States: 10!?
x := 2P =

7. while true do
x := 0
Maude> search P =>* Q .
Zzz...
P =
MORE ANNOYANCES...

8. THE FREE LUNCH IS OVER
Herb Sutter. “The free lunch is over”, Dr. Dobb's Journal, 30(3), March 2005 and C/C++
Users Journal, 23(2), February 2005.
<
“some optimizations are
actually far more than
optimizations, in that they can
change the meaning of
programs and cause visible
effects that can break
reasonable programmer
expectations.
CPU designers are generally
sane and well-adjusted folks
but they are under so much
pressure that they'll risk
changing the meaning of your
program, and possibly break it,
in order to make it run faster. “

9. Dekker Peterson Lamport Szymanski
0
100
200
300
400
500
600
700
800
900
1000
Sequentially Consistent
Relaxed (incorrect)
Relaxed (corrected)
STATE SPACE SIZE: SC vs RMM

10. Dekker Peterson Lamport Szymanski
0
200
400
600
800
1000
1200
No reduction
Some approximation
Some other approximation
Partial-Order-Reduction
Some combination
REDUCTIONS (verification)

11. Dekker Peterson Lamport Szymanski
0
50
100
150
200
250
300
350
400
450
Breadth-First Search
Best-First with some heuristic
Best-First with some other heuristic
Best-First with yet another heuristic
REDUCTIONS (bug-finding)

12. RELAXED
MEMORY MODELS

13. SEQUENTIAL CONSISTENCY
“A multiprocessor system is sequentially consistent if
the result of any execution is the same as if the
operations of all the processors were executed in
some sequential order, and the operations of each
individual processor appear in this sequence in the
order specified by its program.”
- Leslie Lamport, "How to Make a Multiprocessor Computer That
Correctly Executes Multiprocess Programs", IEEE Trans. Comput, 1979
Program order: among operations from
individual processors
Atomicity: memory operations must execute
atomically with respect to each other

14. RELAXING CONSISTENCY
Relaxing program order:

Write-to-Read

Write-to-Write

Read-to-Read

Read-to-Write
Relaxing atomicity:

Read own write early

Read others’ write early

15. HIERARCHY OF RELAXATIONS
SC
TSO IBM-370
PC
RCsc
PowerPC
WO Alpha
RCPc
RMO
PSO
Write-to-Read
Write-to-Write
Read-to-Read
Read-to-Write
source: http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_506_Spring_2013/10c_ks

16. TOTAL STORE ORDERING (TSO)
Relaxations:

Write-to-Read

Read own write early
Why?

Mitigate write latency

Some programs may still be “correct”
(e.g. sequentially consistent)

17. TSO “AXIOMATICALLY”
TSO-executions are sequences of reads and writes
r(x,u) < r(y,v) < w(z,w) < ...

18. TSO “AXIOMATICALLY”
TSO-executions are sequences of reads and writes
r(x,u) < r(y,v) < w(z,w) < ...
such that
r <p r' => r < r' [r-r preserved]
r <p w' => r < w' [r-w preserved]
w <p w' => w < w' [w-w preserved]
w-r allowed

19. TSO “AXIOMATICALLY”
TSO-executions are sequences of reads and writes
r(x,u) < r(y,v) < w(z,w) < ...
such that
r <p r' => r < r' [r-r preserved]
r <p w' => r < w' [r-w preserved]
w <p w' => w < w' [w-w preserved]
and
r(x,u) are such that
(1) v if s(x,v) is the max wrt. < among all s(x,v) s.t.
s(x,v) < r(x,u) or
s(x,v) <p r(x,u)
(2) x0 (initial value for x) if there is no s(x,v) above.
(read own's write early)
w-r allowed

20. TSO “OPERATIONALLY”
SHARED MEMORY
THREAD THREAD

21. TSO “OPERATIONALLY”
SHARED MEMORY
THREAD THREAD
WRITE BUFFER WRITE BUFFER

22. Formalization of memory models
 Axiomatic [Adve, Alglage, Sewel, Owens, Higham,...]
 Operational [Boudol, Petri, Atig, Bouajjani, Burckhardt,...]
 Adequacy, generality, etc.
Correctness criteria
 Sequential consistency, linearizability, serializability,
quiescent/eventual consistency... [Herlihy, Shavit, Shapiro,...]
 “Fundamental property” (data-race free programs are
sequential consistent) [Saraswat et al.]
Portability of programs
 Check whether P/SC ≈ P/RMM
 Otherwise repair P e.g. inserting fences [Wolper, Bouajjani...]
SOME KEY ISSUES

23. Verification approaches
 Directly use SC verification tools
e.g. for programs that are linearizable even under
RMMs [Burckhardt, Cohen, Owens]
 Program Transformation and then SC tools
e.g. [Alglave, Bouajjani]
 Ad-hoc verification under RMMs.
e.g. Some... (see later)
Some tools
 CBMC [Alglave et al]
 CheckFence [Burckhardt et al]
 DFENCE [Lui et al]
SOME KEY ISSUES

24. THIS TALK's
PERSPECTIVE

25. OUR SPIRIT HERE
 Language designers prototyping new RMM-
aware languages with Maude (the natural
framework!).
 Interested in “search” for P/RMM (for checking
properties, for fence insertions, etc.).
 Willing to make search efficient but not willing
to modify the Maude engine.

26. A SIMPLE
MULTI-THREADED
LANGUAGE

27. A SIMPLE LANGUAGE

28. CONFIGURATIONS

29. MEMORIES AND VIEWS
Memory updates
Local to Global
In the following abbreviates

30. SEMANTICS: thread interleaving
sorry...

31. SEMANTICS: skip

32. SEMANTICS: assignments

33. SEMANTICS: fences

34. SEMANTICS: sequential composition

35. SEMANTICS: branches

36. SEMANTICS: loops

37. SEMANTICS: wait

38. SEMANTICS: buffer commits

39. MORE ANNOYANCES...
x := 1
Maude> search P =>* Q .
...
States: 10!?
x := 2P =

40. x|->0
===============
||
---------------
x:=1; || x:=2;
x|->0
===============
x|->1 ||
---------------
skip || x:=2;
x|->0
===============
|| x|->2
---------------
x:=1 || skip
x|->0
===============
x|->1 || x|->2
---------------
skip || skip
x|->1
===============
||
---------------
skip || x:=2;
x|->2
===============
||
---------------
x:=1 || skip
x|->1
===============
|| x|->2
---------------
skip || skip
x|->1
===============
||
---------------
skip || skip
x|->2
===============
x|->1 ||
---------------
skip || skip
x:=1;
x:=1;
x:=1;
x:=2;
x:=2;
x:=2;
commit commit
commit commit
commitcommit
x|->2
===============
||
---------------
skip || skip
state
Shared memory
Thread buffer
Thread program

41. x|->0
===============
||
---------------
x:=1; || x:=2;
x|->0
===============
x|->1 ||
---------------
skip || x:=2;
x|->0
===============
|| x|->2
---------------
x:=1 || skip
x|->0
===============
x|->1 || x|->2
---------------
skip || skip
x|->1
===============
||
---------------
skip || x:=2;
x|->2
===============
||
---------------
x:=1 || skip
x|->1
===============
|| x|->2
---------------
skip || skip
x|->1
===============
||
---------------
skip || skip
x|->2
===============
x|->1 ||
---------------
skip || skip
x:=1;
x:=1;
x:=1;
x:=2;
x:=2;
x:=2;
commit commit
commit commit
commitcommit
x|->2
===============
||
---------------
skip || skip
state
Shared memory
Thread buffer
Thread program
Usual state
space with SC

42. while true do
x := 0
Maude> search P =>* Q .
Zzz...
P =
MORE ANNOYANCES...

43. x|->0
====================
--------------------
while(true) do x:=0
x|->0
====================
--------------------
x:=0;
while(true) do x:=0
while(true)
x:=0;
x|->0
====================
x|->0
--------------------
while(true) do x:=0
x|->0
====================
x|->0
--------------------
x:=0;
while(true) do x:=0
while(true)
x|->0
====================
x|->0
x|->0
--------------------
while(true) do x:=0
while(true)
x:=0;
commit
commit
commit
...

44. SOME
REDUCTION
TECHNIQUES

45. Partial Order Reduction Techniques
 Partial Orders [Alglave et al. @ CAV 2013]
 Persistent Sets [Linden&Wolper @ TACAS 2013]
 Ample sets (via SPIN) [Jonson @ CAN2009]
Approximation/abstraction techniques
 Predicate abstraction [Dan et al. @ SAS 2013]
 Bounded context-switches [Abdulla et al. @ TACAS 2012]
 Single-buffer semantics [Atig et al. @ CAV 2011]
 Buffers-as-sets abstraction [Kuperstein et al. @ PLDI 2011]
 Bounded buffers [Kuperstein et al. @ FMCAD 2011]
Other
 SAT/BMC [Burckhardt et al @ CAV 6/7/8, Gopalakrishnan et al. @ CAV 04]
 Buffer automata [Linden&Wolper @ SPIN2010, TACAS 2013]
 Monitors [Burnim et al. @ TACAS 2011, Burckhardt&Musuvathi @ CAV 2008]
TEN+ YEARS OF RESEARCH
Equational abstractions? [Meseguer&Palomino&Martí-Oliet @ TCS 2008]
Partial-order reduction? [Farzan&Meseguer @ TERMGRAPH 2006]
Search strategies? [Martí-Oliet&Meseguer&Verdejo @ WRLA 2004]

46. SOME SIMPLE
APPROXIMATIONS
FOR TSO
Disclaimer: proof-of-concepts, for the
“good” ones see the above cited papers.

47. ONE OF OUR ANOYANCES
while true do
x := 0
Maude> search P =>* Q .
Zzz..

48. BUFFERS AS SETS OF UPDATES
Abstract buffers as sets of updates:
 Make ACI1 (i.e. buffer becomes sets of updates);
 Make commit non-deterministic (usual+no effect);
 Make evaluation of expressions non-deterministic.
You get an over-approximation:
 Finite state space;
 Preservation of reachability properties.
 (Possibly) some “spurious” behaviours;

49. Dekker Peterson Lamport Szymanski
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
No reduction
Buffers-as-Sets
Buffers-as-Ordered-Maps
Force-Flush
MORE STATES

50. BUFFERS AS ORDERED MAPS
Approximation that
 Guarantees finite state space;
 Introduces some executions;
 Preserves some reachability properties???
(under investigation)

51. “SPURIOUS” EXECUTIONS
x:=1;
y:=1;
x:=2
wait x=0 & y=1

52. x|->0 , y |->0
===============
||
---------------
x:=1; || wait(...)
y:=1; ||
x:=2 ||
x|->0 , y |->0
===============
x|->1 ||
---------------
y:=1; || wait(...)
x:=2; ||
x|->0 , y |->0
===============
x|->1 ||
y|->1 ||
---------------
x:=2; || wait(...)
x|->0 , y |->0
===============
x|->1 ||
y|->1 ||
x|->2 ||
---------------
skip || wait(...)
x|->1 , y |->0
===============
||
---------------
y:=1; || wait(...)
x:=2; ||
x|->1 , y |->0
===============
y|->1 ||
---------------
x:=2; || wait(...)
x|->1 , y |->0
===============
y|->1 ||
x|->2 ||
---------------
skip || wait(...)
x|->1 , y |->1
===============
||
---------------
x:=2; || wait(...)
x|->1 , y |->1
===============
x|->2 ||
---------------
skip || wait(...)
x|->2 , y |->1
===============
||
---------------
skip || wait(...)
commit
commitcommit
commit
commit
commit
x|->0 , y |->0
===============
y|->1 ||
x|->2 ||
---------------
skip || wait(...)
wait!
ONE “SPURIOUS”
EXECUTION
x|->0 , y |->1
===============
y|->1 ||
---------------
skip || wait(...)
commit

53. Dekker Peterson Lamport Szymanski
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
No reduction
Buffers-as-Sets
Buffers-as-Ordered-Maps
Force-Flush
REDUCTIONS

54. FORCE-FLUSH APPROXIMATION
Under-approximation that
 Does not guarantee finite state space ;
 Some behaviours may be lost;
 Does not introduce spurious behaviours.
(up to some equivalence: stuttering and
depending on the state observations).

55. M
===============
x|->u ||
... ||
x|->v ||
---------------
S || T
M ◦ x|->u
===============
... ||
x|->v ||
---------------
S || T
NO “SPURIOUS” EXECUTION
M
===============
x|->u ||
... ||
||
---------------
x:=v; S || T
M ◦ x|->u
===============
... ||
||
---------------
x:=v; S || T
commit
x:=v x:=v
(up to some equivalence: stuttering and
depending on the state observations).

56. Dekker Peterson Lamport Szymanski
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
No reduction
Buffers-as-Sets
Buffers-as-Ordered-Maps
Force-Flush
REDUCTIONS

57. PARTIAL-ORDER
REDUCTION
FOR RMMs

58. AMPLE SETS
Main idea
 Explore only a subset ample(s) of the succesors of s...
 ...such that ample(s):
C0: ample(s) empty only if s is a deadlock;
C1: ample(s) contains invisible actions;
C2: no transition that is dependent on a transition in
ample(s) occurs in the original system without a
transition in ample(s) occurring first;
C3: no action outside ample(s) is delayed forever.
 You will get a stutter equivalent transition system.

59. SIMPLE POR FOR TSO
Simple heuristic: assignments
x := u
are independent of actions of other threads
since their effect is local (on the buffer).
They are also invisible unless one wants to
observe buffers or programs.

60. Dekker Peterson Lamport Szymanski
0
100
200
300
400
500
600
700
800
900
1000
No reduction
Partial-Order Reduction
REDUCTIONS (verification)

61. SEARCH
STRATEGIES
FOR RMMs

62. DIRECTED MODEL CHECKING
Main idea
 Replace the exploration algorithm (NDFS/BFS)
by a “guided” algorithm (A*, Best-First, etc.)
 Domain/property-based “heuristic” functions
to rank states or executions
“Heuristics for model checking Java” [Groce&Visser]
 Promote interleavings (we think “sequentially”)
 Promote code coverage
Done for JPF, SPIN, etc.

63. x|->0 , y|->0
===============
||
---------------
x:=1; || y:=1;
y==0? || x==0?
x|->0 , y|->0
===============
x->1 ||
---------------
y==0? || y:=1;
|| x==0?
x|->0 , y|->0
===============
|| y->1
---------------
x:=1 || x==0?
y==0? ||
x|->0 , y|->0
===============
x->1 || y->1
---------------
y==0? || x==0?
x|->1 , y|->0
===============
||
---------------
y==0? || y:=1;
|| x==0?
x|->0 , y|->1
===============
||
---------------
X:=1 || x==0?
y==0? ||
x:=1;
x:=1;
y:=1;
y:=1;flush flush
... ...
x|->0 , y|->0
===============
x->1 || y->1
---------------
cs || x==0?
x|->0 , y|->0
===============
x->1 || y->1
---------------
y==0? || cs

64. x|->0 , y|->0
===============
||
---------------
x:=1; || y:=1;
y==0? || x==0?
x|->0 , y|->0
===============
x->1 ||
---------------
y==0? || y:=1;
|| x==0?
x|->0 , y|->0
===============
|| y->1
---------------
x:=1 || x==0?
y==0? ||
x|->0 , y|->0
===============
x->1 || y->1
---------------
y==0? || x==0?
x|->1 , y|->0
===============
||
---------------
y==0? || y:=1;
|| x==0?
x|->0 , y|->1
===============
||
---------------
X:=1 || x==0?
y==0? ||
x:=1;
x:=1;
y:=1;
y:=1;flush flush
0
0
0
2
1
0
0
0
1
... ...
x|->0 , y|->0
===============
x->1 || y->1
---------------
cs || x==0?
x|->0 , y|->0
===============
x->1 || y->1
---------------
y==0? || cs
2 2
Count number of
non-empty buffers

65. Dekker Peterson Lamport Szymanski
0
50
100
150
200
250
300
350
400
450
Breadth-First Search
Best-First + "number of non-empty buffers" heuristic
Best-First + "number of pending writes" heuristic
Best-First + "number of inconsistent pending writes" heuristic
REDUCTIONS (bug-finding)

66. CONCLUDING
REMARKS

67. I would say yes.
Worth investigating
Can we efficiently verify concurrent programs
under relaxed memory models in Maude?

68. Beyond TSO: PSO, RMO, etc.1
2
FUTURE WORK?
Other languages/primitives: see e.g.
KernelC/x86-TSO in K [Serbanuta]
3 Proof techniques (with Maude)

69. TAHNSK!

70. REFERENCES

71. [Linden&Wolper @ TACAS 2013]
Alexander Linden, Pierre Wolper: A Verification-Based Approach to Memory Fence
Insertion in PSO Memory Systems. TACAS 2013: 339-353
[Dan&MMeshman&Vechev&Yahav @ SAS 2013]
Andrei Marian Dan, Yuri Meshman, Martin T. Vechev, Eran Yahav: Predicate
Abstraction for Relaxed Memory Models. SAS 2013: 84-104
[Alglave et al. @ CAV 2013]
Jade Alglave, Daniel Kroening, Michael Tautschnig: Partial Orders for Efficient
Bounded Model Checking of Concurrent Software. CAV 2013: 141-157
[Abdulla&Atig&Chen&Leonardsson&Rezine @ TACAS 2012]
Abdulla, P.A., Atig, M.F., Chen, Y.-F., Leonardsson, C., Rezine, A.: Counter- Example
Guided Fence Insertion under TSO. In: TACAS 2012. LNCS, vol. 7214 (2012)
[Atig&Bouajjani&Parlato @ CAV 2011]
Atig, M.F., Bouajjani, A., Parlato, G.: Getting Rid of Store-Buffers in TSO Analysis. In:
Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806 (2011)
[Kuperstein&Vechev&Yahav @ PLDI 2011]
Kuperstein, M., Vechev, M., Yahav, E.: Partial-coherence abstractions for relaxed
memory models. In: PLDI 2011 (2011)
REFERENCES (1)

72. [Burnim&Sen&Stergiou @ TACAS 2011]
Jacob Burnim, Koushik Sen, Christos Stergiou: Sound and Complete Monitoring of
Sequential Consistency for Relaxed Memory Models. TACAS 2011: 11-25
[Burnim&Sen& C. Stergiou @ TACAS 2011]
J. Burnim, K. Sen, and C. Stergiou. Sound and complete monitoring of sequential
consistency in relaxed memory models. In TACAS, 2011.
[Kuperstein&Vechev&Yahav @ FMCAD 2011]
M. Kuperstein, M. Vechev, and E. Yahav. Automatic inference of memory fences. In
FMCAD, 2011.
[Linedn&Wolper @ SPIN 2010] A. Linden and P. Wolper. An automata-based symbolic
approach for verifying programs on relaxed memory models. In SPIN, 2010.
[Jonson @ CAN2009]
Jonsson, B.: State-space exploration for concurrent algorithms under weak memory
orderings: (preliminary version). SIGARCH Comput. Archit. News 36, 65–71 (2009)
[Burckhardt&Musuvathi @ CAV 2008]
Burckhardt,S.,Musuvathi,M.: Effective Program Verification for Relaxed Memory
Models. In: Gupta, A., Malik, S. (eds.) CAV 2008. LNCS, vol. 5123, pp. 107–120.
Springer, Heidelberg (2008)
REFERENCES (2)

73. [Burckhardt&Alur&Martin @ CAV 2007]
Burckhardt, S., Alur, R., Martin, M.M.K.: Checkfence: checking consistency of
concurrent data types on relaxed memory models. In: ACM SIGPLAN 2007
Conference on Programming Lan- guage Design and Implementation (2007)
[Burckhardt&Alur&Martin @ CAV 2006]
Burckhardt,S.,Alur,R.,Martin,M.M.K.: Bounded Model Checking of Concurrent Data
Types on Relaxed Memory Models: A Case Study. In: CAV 2006. LNCS 4144. (2006)
[Gopalakrishnan&Yang&Sivaraj @ CAV 2004]
Gopalakrishnan, G., Yang, Y., Sivaraj, H.: QB or not QB: An efficient execution
verification tool for memory orderings. In: CAV 2004. LNCS, vol. 3114 (2004)
[Park&Dill @ PAA 1995]
Park, S., Dill, D.L.: An executable specification, analyzer and verifier for rmo (relaxed
memory order). In: SPAA 1995: Proceedings of the Seventh Annual ACM Symposium
on Parallel Algorithms and Architectures, pp. 34–41. ACM, New York (1995)
REFERENCES (3)

74. [Meseguer&Palomino&Martí-Oliet @ TCS 2008]
José Meseguer, Miguel Palomino, Narciso Martí-Oliet: Equational abstractions. Theor.
Comput. Sci. 403(2-3): 239-264 (2008)
[Farzan&Meseguer @ TERMGRAPH 2006]
Azadeh Farzan, José Meseguer: Partial Order Reduction for Rewriting Semantics of
Programming Languages. Electr. Notes Theor. Comput. Sci. 176(4): 61-78 (2007)
[Rodríguez 2009 @ WRLA 2009]
Rodríguez, D.E.: Combining techniques to reduce state space and prove strong
properties. In: WRLA. Volume 238(3) of ENTCS. (2009) 267 – 280
[Lluch&Meseguer&Vandin @ ICFEM 2012]
Alberto Lluch-Lafuente, José Meseguer, Andrea Vandin: State Space c-Reductions of
Concurrent Systems in Rewriting Logic. ICFEM 2012: 430-446
[Martí-Oliet&Meseguer&Verdejo @ WRLA 2004]
Narciso Martí-Oliet, José Meseguer, Alberto Verdejo: Towards a Strategy Language
for Maude. Electr. Notes Theor. Comput. Sci. 117: 417-441 (2005)
[Groce&Visser @ STTT 2004]
Alex Groce, Willem Visser: Heuristics for model checking Java programs. STTT 6(4):
260-276 (2004)
REFERENCES (4)