and Software Memory Models

errorhandleΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

53 εμφανίσεις

ICFEM 2002, Shanghai

Reasoning about Hardware
and Software Memory Models

Abhik Roychoudhury

School of Computing

National University of Singapore

ICFEM 2002, Shanghai

Salient Points


Memory Model



What ?


Hardware and Software Memory Models


Why ?


Memory Model: Formal Executable Specs.


Comparing Memory Models for efficiency


MM comparison for reasoning about programs


Concluding Remarks

ICFEM 2002, Shanghai

Memory Model


Order in which memory operations (read / write)
appear to execute to the programmer.


For uni
-
processors, the MM is s.t.


Memory Read / Write appear to execute one at a
time
(atomic)


They execute in the
program order
.

ICFEM 2002, Shanghai

Memory Model

Traditionally used to describe allowed behaviors of
shared memory multiprocessors.

….

Proc 1

Proc 2

Proc n

SHARED MEMORY

ICFEM 2002, Shanghai

Hardware Memory Models

Initially
Data1 = 0


Data2 = 0


Flag = 0

Data1 := 42;

Data2 := Data1

Flag := 1;

||

While (Flag != 1) {};

Register := Data2

Programmer’s intuition:

Register should be 42, not 0

SEQUENTIAL CONSISTENCY

ICFEM 2002, Shanghai

Sequential Consistency


Simple extension of Uni
-
processor model.


Each processor executes in program order.


Operations appear to execute one at a time in some
sequential order.


Other relaxed Memory models also possible.


Certain (not all ) operations in a processor may be
executed
out
-
of
-
order.




ICFEM 2002, Shanghai

Relaxed Memory Models

Initially
Data1 = 0


Data2 = 0



Flag = 0

Data1 := 42;

Data2 := Data1;

Flag := 1;

While (Flag != 1) {};

Register := Data2

Data1 := 42; Data2 := Data1
and
Flag := 1
can
be re
-
ordered e.g.
SPARC PSO

Register = 0
is also possible

ICFEM 2002, Shanghai

Multithreaded programming


Multithreaded programming on multiprocessors is
difficult due to the hardware memory model.


The execution platform supports behaviors other than
Sequential Consistency.


Shared memory parallelism is becoming important
because of Symmetric Multiprocessors (SMP).


Multithreaded program popularized by Java.


Your multithreaded Java program may run diff.
threads on diff. processors without you knowing it !


ICFEM 2002, Shanghai

Java Multithreading


Can structure different parts of the program as diff.
threads e.g. the User Interface as separate thread.


Threads communicate via shared variables.


Threads can run on uni
-

or multi
-
processors.


Semantics called the
Java Memory Model (JMM)


JMM describes all possible allowed behaviors of a
pgm. on any implementation (uni
-

/ multi
-
processor).


Supports locking of shared variables via
synchronized

statements.

ICFEM 2002, Shanghai

Java Memory Model


Weaker than S.C.
(to allow compiler/hardware opt.)


Each shared variable has


Master copy


Local copy in each thread


Threads read/write local/master copies on actions.


Imposes ordering constraints on actions. But does
not impose total order on actions in a thread.


Being considered for revision. Future JMMs are also
bound to be weaker than S.C.

ICFEM 2002, Shanghai

Compiler

Multithreaded Java Pgm

JVM

(Introduce barriers ?)

Hardware MM

(Abstraction of
multiprocessor)

Bytecode

Hardware
Instructions



Should
respect
JMM

ICFEM 2002, Shanghai

Hardware and Software MM


MM
1

> MM
2



Behaviors allowed by MM
1



Behaviors allowed by MM
2


Memory barriers introduced by JMM to prevent certain
behaviors if the hardware MM is too weak.


If we prove:
JMM > Hardware MM


JVM can be tuned to avoid inserting any memory barrier.


If we have:
JMM > HW MM
1

> HW MM
2


Certain multithreaded Java programs can behave differently
on different multiprocessor platforms !!


Need to formally specify and analyze MMs


ICFEM 2002, Shanghai

Developing Exec. Spec.


Hard !


JMM imposes ordering constraints on read/write
actions of shared variables.


The ordering constraints are given informally as set
of rules which must never be violated.


Past work: Operational exec. spec. of JMM [ICSE02]


Th
1

|| Th
2

|| … || Th
n
|| Memory (Asynchronous Composition)


Th
i
executes read/write actions which are modeled as
guarded commands


Executable Spec. of Hardware MMs (e.g. TSO/PSO
from Sun SPARC) developed earlier [Dill et. al. 93]


ICFEM 2002, Shanghai

Total Store Order (TSO)


One of the hardware memory models in Sun SPARC.


All instructions complete in program order,
Except



can complete as




Write completion can be delayed.


store u; store v
cannot be re
-
ordered.


store u; load u

cannot be re
-
ordered.

Store u;

Load v

Load v;

Store u

ICFEM 2002, Shanghai

Comparing JMM and TSO

Only re
-
ordering allowed is store

load

Initially u = v = 0

Store u,1

Load v, reg1

Store v,1

Load u, reg2

Seq. Consistency: reg1 = 1


r敧e 㴠=

呓传› ⁲敧e 㴠= 潲 ㄬ ⁲敧e 㴠= 潲 1

JMM > TSO (Proved by JMM checker)

JVM can execute on TSO without barriers.

ICFEM 2002, Shanghai

Comparing Memory Models


1. Develop
formal executable

specifications of
software and hardware memory models M
s
, M
h


2. Select terminating test programs {P
1
,…,P
k
} which
exploit the re
-
orderings allowed by M
h


Based on informal understanding of M
h


Typically lifted from multiprocessor architecture manuals.


3. Verify that the set of selected test programs
{P
1
,…,P
k
} is complete w.r.t. the re
-
orderings of M
h


Formal reasoning step. Automated if the test programs are
selected methodically.


ICFEM 2002, Shanghai

Comparing Memory Models


4. Perform reachable state space exploration (as in
Model Checking
) of test programs {P
1
,…,P
k
} on
executable models M
h

and M
s


Use formal executable specs of M
h

and M
s


Generate all possible behaviors of test pgms on M
h

and M
s


Automated formal reasoning step


5. Check whether the re
-
orderings of M
h

exposed by
programs {P
1
,…,P
k
} are also allowed by M
s



Combines formal and informal reasoning.

ICFEM 2002, Shanghai

Another Application


Unsynchronized programs: Multithreaded programs
where threads access shared variables without locks.


Allow more behaviors under relaxed hardware MMs.


Use executable specification of JMM to find all
possible behaviors.


If any of these is “unexpected”


Can be manifested
in
certain (not all)

Multiprocessor platforms !!


Verify presence / absence of this behavior by using
executable versions of Hardware memory models.

ICFEM 2002, Shanghai

Unsynchronized Programs

Allowed behaviors differ on different HW Mem. Models.

Used in low
-
level libraries which are executed often.

Data1 := 42;

Data2 := Data1

Flag := 1;

||

While (Flag != 1) {};

Register := Data2

Absence of locks allows write re
-
orderings in a
thread to be visible in other threads.

ICFEM 2002, Shanghai

Idiom for lazy instantiation of a singleton


Double
checked Locking

idiom.

Check whether garbage data
-
fields can be returned

If (inst == null)


synchronized(Singleton.class){


if (inst == null) {


inst = new Singleton();


}

Return inst;

Case Study

Run by

each thread

ICFEM 2002, Shanghai

Results from DC Locking


Allowed behaviors from JMM checker show


Incompletely instantiated object can be returned.


Due to re
-
ordering of writes within constructor.


Allowed behaviors from TSO checker show


Incompletely instantiated obj. cannot be returned.


Proved by State Space Exploration in 0.01 s


Other hardware MM (such as Partial Store Order)
can show this behavior : proved by PSO checker.


ICFEM 2002, Shanghai

Concluding Remarks


Formal understanding of MMs was necessary for low
-
level multiprocessor code.


Advent of Java multithreading and SMP requires us
to understand hardware MMs for running low
-
level
multithreaded Java code.


Language level memory model in Java (JMM)
necessitates comparison of JMM with hardware MMs


Accomplished by formal Executable Specifications
and formal analysis techniques (Model Checking).