Reasoning about hardware and software memory models
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

Reasoning about Hardware and Software Memory Models PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on
  • Presentation posted in: General

Reasoning about Hardware and Software Memory Models. Abhik Roychoudhury School of Computing National University of Singapore. Salient Points. Memory Model – What ? Hardware and Software Memory Models – Why ? Memory Model: Formal Executable Specs. Comparing Memory Models for efficiency

Download Presentation

Reasoning about Hardware and Software Memory Models

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Reasoning about hardware and software memory models

Reasoning about Hardware and Software Memory Models

Abhik Roychoudhury

School of Computing

National University of Singapore

ICFEM 2002, Shanghai


Salient points

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

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 model1

Memory Model

Traditionally used to describe allowed behaviors of shared memory multiprocessors.

Proc n

Proc 1

Proc 2

….

SHARED MEMORY

ICFEM 2002, Shanghai


Hardware memory models

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

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

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

  • 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

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

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


Reasoning about hardware and software memory models

Multithreaded Java Pgm

Compiler

Bytecode

JVM

(Introduce barriers ?)

Should respect JMM

Hardware Instructions

Hardware MM

(Abstraction of multiprocessor)

ICFEM 2002, Shanghai


Hardware and software mm

Hardware and Software MM

  • MM1 > 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 > Hardware MM

    • JVM can be tuned to avoid inserting any memory barrier.

  • If we have: JMM > HW MM1 > HW MM2

    • 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

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]

ICFEM 2002, Shanghai


Total store order tso

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

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 > TSO (Proved by JMM checker)

JVM can execute on TSO without barriers.

ICFEM 2002, Shanghai


Comparing memory models

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.

ICFEM 2002, Shanghai


Comparing memory models1

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.

ICFEM 2002, Shanghai


Another application

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

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


Reasoning about hardware and software memory models

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.class){

if (inst == null) {

inst = new Singleton();

}

Return inst;

Run by

each thread

ICFEM 2002, Shanghai


Results from dc locking

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

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

ICFEM 2002, Shanghai


  • Login