Reasoning about Hardware and Software Memory Models - PowerPoint PPT Presentation

About This Presentation
Title:

Reasoning about Hardware and Software Memory Models

Description:

ICFEM 2002, Shanghai. Reasoning about Hardware and Software Memory Models. Abhik Roychoudhury ... ICFEM 2002, Shanghai. Java Multithreading. Can structure ... – PowerPoint PPT presentation

Number of Views:94
Avg rating:3.0/5.0
Slides: 23
Provided by: soc128
Category:

less

Transcript and Presenter's Notes

Title: Reasoning about Hardware and Software Memory Models


1
Reasoning about Hardware and Software Memory
Models
  • Abhik Roychoudhury
  • School of Computing
  • National University of Singapore

2
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

3
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.

4
Memory Model
Traditionally used to describe allowed behaviors
of shared memory multiprocessors.
Proc n
.
Proc 1
Proc 2
SHARED MEMORY
5
Hardware Memory Models
Initially Data1 0 ? Data2 0 ? Flag 0
Data1 42 Data2 Data1 Flag 1
While (Flag ! 1) Register Data2

Programmers intuition Register should be 42,
not 0 SEQUENTIAL CONSISTENCY
6
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.

7
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
8
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 !

9
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.

10
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.

11
Multithreaded Java Pgm
Compiler
Bytecode
JVM (Introduce barriers ?)
Should respect JMM
Hardware Instructions
Hardware MM

(Abstraction of multiprocessor)
12
Hardware and Software MM
  • MM1 gt MM2
  • Behaviors allowed by MM1 ? Behaviors allowed by
    MM2
  • Memory barriers introduced by JMM to prevent
    certain behaviors if the hardware MM is too weak.
  • If we prove JMM gt Hardware MM
  • JVM can be tuned to avoid inserting any memory
    barrier.
  • If we have JMM gt HW MM1 gt HW MM2
  • Certain multithreaded Java programs can behave
    differently on different multiprocessor platforms
    !!
  • Need to formally specify and analyze MMs

13
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
  • Th1 Th2 Thn Memory (Asynchronous
    Composition)
  • Thi 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

14
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
15
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 ? reg2 1 TSO
reg1 0 or 1, reg2 0 or 1 JMM gt TSO (Proved
by JMM checker) JVM can execute on TSO without
barriers.
16
Comparing Memory Models
  • 1. Develop formal executable specifications of
    software and hardware memory models Ms, Mh
  • 2. Select terminating test programs P1,,Pk
    which exploit the re-orderings allowed by Mh
  • Based on informal understanding of Mh
  • Typically lifted from multiprocessor architecture
    manuals.
  • 3. Verify that the set of selected test programs
    P1,,Pk is complete w.r.t. the re-orderings of
    Mh
  • Formal reasoning step. Automated if the test
    programs are selected methodically.

17
Comparing Memory Models
  • 4. Perform reachable state space exploration (as
    in Model Checking) of test programs P1,,Pk on
    executable models Mh and Ms
  • Use formal executable specs of Mh and Ms
  • Generate all possible behaviors of test pgms on
    Mh and Ms
  • Automated formal reasoning step
  • 5. Check whether the re-orderings of Mh exposed
    by programs P1,,Pk are also allowed by Ms
  • Combines formal and informal reasoning.

18
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.

19
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.
20
Case Study
Idiom for lazy instantiation of a singleton
Double checked Locking idiom. Check whether
garbage data-fields can be returned
If (inst null) synchronized(Singleton.clas
s) if (inst null)
inst new Singleton() Return inst
Run by each thread
21
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.

22
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).
Write a Comment
User Comments (0)
About PowerShow.com