Download new

Specifying Multithreaded
Java semantics for
Program Verification
Abhik Roychoudhury
National University of Singapore
(Joint work with Tulika Mitra)
Java Multithreading
Threads communicate via shared variables.
Threads run on uni- or multi-processors
Semantics given as abstract rules : Java
Memory Model (JMM). Any multithreading
implementation must respect JMM.
Supports locking via synchronized statements
Locking may be avoided for performance.
ICSE 2002, Orlando FL
2
Unsychronized code
synchronized (Singleton.class){
if (inst == null)
inst = new Singleton();
return inst ;
}
if (inst == null)
synchronized (Singleton.class){
if (inst == null)
inst = new Singleton();
}
return inst;
ICSE 2002, Orlando FL
3
Shared variable access
without locks
Initially :
A = 0, B = 0
B = 1;
while (A != 1) {};
A = 1;
return B
||
Expected returned value = 1
ICSE 2002, Orlando FL
4
What may happen
B = 1;
while (A != 1) {};
A = 1;
return B
||
May happen if threads
are executed on different
processors, or even by
compiler re-ordering
A= 1
return B
B = 1
Returned value = 0
ICSE 2002, Orlando FL
5
Sequential Consistency
Programmer expects statements within a thread to
complete in program order: Sequential Consistency
I.
Each thread proceeds in program order
II.
Operations across threads are interleaved
Op1 Op’’ Op2 Op’ violates SC
Op’ ;
Op1;
Op2;
||
ICSE 2002, Orlando FL
Op’’ ;
6
Is this a problem ?
Programmers expect SC
Verification techniques assume SC execution
SC not guaranteed by execution platforms
Not demanded by Java language spec.
Unrealistic for any future spec. to demand
YES !!
ICSE 2002, Orlando FL
7
Organization
Shared variable access without locks
Candidate solutions
Specifying the Java Memory Model
(JMM)
Using JMM for verification
ICSE 2002, Orlando FL
8
1. Program with caution
Always synchronize (and acquire lock) before
writing a shared object
For these programs, any execution is SC
Unacceptable performance overheads for
low-level libraries
Software libraries from other sources cannot
be guaranteed to be properly synchronized
ICSE 2002, Orlando FL
9
2. Change the Semantics
Current semantics called Java Memory
Model (JMM). Part of Java language spec.
Weaker than Sequential Consistency. Allows
certain re-orderings within threads
Currently being considered for revision
Existing/future JMM bound to be weaker than
SC – Does not solve the problem
ICSE 2002, Orlando FL
10
3. Use the semantics
Develop a formal executable description of
the Java Memory Model
Use it for program debugging, verification
JMM captures all possible behaviors for any
implementation – Platform independent
reasoning
Adds value to existing program verification
techniques
ICSE 2002, Orlando FL
11
Organization
Shared variable access without locks
Candidate solutions
Specifying the Java Memory Model
(JMM)
Using JMM for verification
ICSE 2002, Orlando FL
12
JMM Overview
Each shared variable v has
• A master copy
• A local copy in each thread
Threads read and write local/master copies
by actions
Imposes ordering constraints on actions
Not multithreaded implementation guide
ICSE 2002, Orlando FL
13
JMM Actions
read(v,t)
load(v,t)
Master
copy of v
Local copy
of v in t
write(v,t)
store(v,t)
Actions invoked by Program Execution:
use/assign(t,v) Read from/ Write into local copy of v in t
lock/unlock(t) Acquire/Release lock on shared variables
ICSE 2002, Orlando FL
14
Formal Specification
Asynchronous concurrent composition
• Th1 || Th2 || … || Thn || MM
Local state of each thread modeled as cache
• ( Local copy, Stale bit, Dirty bit )
• Queues for incomplete reads/writes
Local state of MM
• ( Master copies, Lock ownership info )
ICSE 2002, Orlando FL
15
Specifying JMM Actions
Each action is a guarded command G  B
Evaluate G; If true execute B atomically
Example: Use of variable v by thread t
•  stale[t,v]  return local_copy[t,v]
Applicability of action stated as guard
In rule-based description, several rules
determine the applicability
ICSE 2002, Orlando FL
16
Understanding JMM
assign(t,v)
assign(t, v)
<
load(t,v)

<
store(t,v)
<
load(t,v)
A store must intervene between an assign
and a load action for a variable v by thread t
ICSE 2002, Orlando FL
17
Understanding JMM
assign(t, v)
assign(t,v)
<
assign(t,v)
<
load(t,v)

store(t,v)
<
load(t,v)
< store(t,v)

< write(t,v)
< read(t,v)
< load(t,v)
read/write actions on the master copy of v by thread t are
performed in the order of corresponding load/store actions
ICSE 2002, Orlando FL
18
Understanding JMM
Applicability of an action depends on several
rules in the rule-based description
This is what makes the model “hard to
understand”
Operation description specifies applicability
as guard
assign(t,v) : empty(read_queue[t,v]) -> ….
ICSE 2002, Orlando FL
19
Executable model
Java threads invoke use,assign,lock,unlock
Action executed by corresponding commands
Threads block if the next action not enabled
To enable these, store,write,load,read are
executed in any order provided guard holds
Example: To enable assign, a load is
executed (if there was an earlier read)
ICSE 2002, Orlando FL
20
Organization
Shared variable access without locks
Candidate solutions
Specifying the Java Memory Model
(JMM)
Using JMM for verification
ICSE 2002, Orlando FL
21
Verifying
Unsynchronized Code
assign(B,1)
assign(A,1)
While (use(A) !=1){}
||
use(B)
use/assign invoke corresponding guarded commands
load/store/read/write executed to enable use/assign
Exhaustive state space exploration shows use(B)
may return 1 or 0
ICSE 2002, Orlando FL
22
Program verification
Composing executable JMM allows search
The state space explosion problem 
Most Java programs are “properly
synchronized” and hence SC execution
Unsynchronized code appears in low-level
fragments which are frequently executed
These programs are small, so … 
ICSE 2002, Orlando FL
23
One possibility
User chooses one program path in each
thread (Creative step)
Exhaustively check all possible execution
traces from chosen program paths
(Automated state space exploration: Can
verify invariants)
Choosing program paths requires
understanding source code, not JMM
ICSE 2002, Orlando FL
24
Case Study:
Double Checked Locking
Idiom for lazy instantiation of a singleton
Check whether garbage data-fields can be
returned by this object initialization routine
Verification by composing the JMM reveals:
• Incompletely instantiated object can be returned
• Due to re-ordering of writes within constructor
• Detected by prototype invariant checker in 0.15 sec
ICSE 2002, Orlando FL
25
Summary
Executable specification of Multithreaded
Java semantics
Using the specification for debugging
multithreaded programs
Similar approach has been studied before in
the context of hardware multiprocessors
How to correct the bugs found (the harmful
re-orderings) ?
ICSE 2002, Orlando FL
26