Static Analysis of Race-Free Interrupt-Driven Programs Deepak - - PowerPoint PPT Presentation

▶
static analysis of race free interrupt driven programs
SMART_READER_LITE
LIVE PREVIEW

Static Analysis of Race-Free Interrupt-Driven Programs Deepak - - PowerPoint PPT Presentation

Nov 29, 2022 501 likes •984 views

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis Static Analysis of Race-Free Interrupt-Driven Programs Deepak DSouza Department of Computer Science and Automation Indian Institute of Science,

slide-1
SLIDE 1

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Static Analysis of Race-Free Interrupt-Driven Programs

Deepak D’Souza

Department of Computer Science and Automation Indian Institute of Science, Bangalore.

FM Update, BITS Goa, 19 July 2018. Joint work with Nikita Chopra and Rekha Pai

slide-2
SLIDE 2

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Outline

1

Data Flow Analysis

2

Concurrent Programs

3

Race-Free Programs

4

Sync-CFG Analysis

5

Analysis

slide-3
SLIDE 3

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

1. p := 17; 2. q := 10; 3. while (p > q) { 4. p := p + 1; 5. q := q + 2; 6. } 7. print p, q;

slide-4
SLIDE 4

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (e, e)

slide-5
SLIDE 5

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (o, e)

slide-6
SLIDE 6

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (o, e)

slide-7
SLIDE 7

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (o, e)

slide-8
SLIDE 8

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (o, e)

slide-9
SLIDE 9

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (e, e)

slide-10
SLIDE 10

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data-Flow Analysis / Abstract Interpretation Aim: To obtain conservative facts about the program state at each program point. Use abstract states to represent the concrete state. Example: Concrete state: p → 17, q → 10 Abstract state: p → o, q → e. Interpret execution along a path by transforming the abstract state.

B p > q F p:=p+1 A C D E q:=q+2 q:= 10 p:= 17 print p,q (e, e)

slide-11
SLIDE 11

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) ⊥ ⊥ ⊥ ⊥ ⊥ ⊥ (o, e) (e, e)

slide-12
SLIDE 12

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (o, e) ⊥ ⊥ ⊥ ⊥ ⊥ (o, e) (e, e)

slide-13
SLIDE 13

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (o, e) (o, e) (o ⊥ ⊥ ⊥ (o, e) (e, e)

slide-14
SLIDE 14

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (o, e) (e, e) (o, e) (o ⊥ ⊥ (o, e) (e, e)

slide-15
SLIDE 15

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (o, e) (o, e) (e, e) (o (e, e) ⊥ (o, e) (e, e)

slide-16
SLIDE 16

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (o, e) (oe, e) (e, e) (o (e, e) ⊥ (o, e) (e, e)

slide-17
SLIDE 17

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (oe, e) (oe, e) (e, e) (e, e) ⊥ (o (o, e) (e, e)

slide-18
SLIDE 18

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (oe, e) (oe, e) (e, e) ⊥ (oe, e) (o (o, e) (e, e)

slide-19
SLIDE 19

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (oe, e) (oe, e) (oe, e) ⊥ (oe, e) (o (o, e) (e, e)

slide-20
SLIDE 20

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (o, e) (oe, e) (oe, e) ⊥ (oe, e) (o (oe, e) (o, e) (e, e)

slide-21
SLIDE 21

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (oe, e) (o, e) (oe, e) (oe, e) (o (oe, e) (oe, e) (o, e) (e, e)

slide-22
SLIDE 22

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Computing JOP/LFP

(e, oe) ⊥ (e, e) (oe, oe) (o, oe) (oe, o) (oe, e) (o, e) (e, o) (o, o)

We usually further over-approximate the JOP by computing the least fixpoint (LFP) (least solution)

  • f data-flow equations.

The number of steps in the LFP computation is bounded by

number of program points × height of abstract lattice.

B p > q F p:=p+1 C D E G q:=q+2 A q:= 10 p:= 17 print p,q (oe, e) (o, e) (oe, e) (oe, e) (o (oe, e) (oe, e) (o, e) (e, e)

slide-23
SLIDE 23

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Multi-Threaded Programs Standard interleaving semantics

main:

  • 1. x := 0;
  • 2. y := 0;
  • 3. spawn(t1);
  • 4. spawn(t2);

5. t1: t2:

  • 1. if (x < 10)
  • 1. if (x < 10)

2. x++; 2. x++;

  • 3. y++
  • 3. y++

4. 4.

(1, 1, 1), (x → 0, y → 1), (e, d, d) (2, 1, 1), (x → 0, y → 1), (e, d, d) (3, 1, 1), (x → 0, y → 1), (e, d, d) (4, 1, 1), (x → 0, y → 1), (e, e, d) (4, 2, 1), (x → 0, y → 1), (e, e, d) (5, 1, 1), (x → 0, y → 1), (e, e, e) (5, 2, 1), (x → 0, y → 1), (e, e, e) (5, 1, 2), (x → 0, y → 1), (e, e, (5, 3, 1), (x → 0, y → 1), (e, e, e) (5, 4, 1), (x → 1, y → 1), (e, e, e)

slide-24
SLIDE 24

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Product Control Flow Graph

main:

  • 1. x := 0;
  • 2. y := 0;
  • 3. spawn(t1);
  • 4. spawn(t2);

5. t1: t2:

  • 1. if (x < 10)
  • 1. if (x < 10)

2. x++; 2. x++;

  • 3. y++
  • 3. y++

4. 4.

y++ y++ x :− 0 y :− 0 spawn(t1) spawn(t2) assume(x<10) x++ assume(x<10) spawn(t2) assume(x<10)

(5, 4, 4) (5, 3, 4) (5, 4, 3) (1, 1, 1) (2, 1, 1) (3, 1, 1) (4, 1, 1) (4, 2, 1) (5, 1, 1) (5, 2, 1) (5, 1, 2)

slide-25
SLIDE 25

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Data Flow Analysis for a Concurrent Program Naive approach: Construct Product CFG Carry out analysis on this graph Approach is precise, but too expensive! Problem: If number of threads is k, height of lattice is h, and number of program points in a thread is n, then Number of program points in product CFG is nk. Number of iterations is bounded by h × nk Time taken can be exponential in number of threads. Can we be more efficient for some class of programs, maybe at the cost of precision?

slide-26
SLIDE 26

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Happens-Before Race

Happens-Before ordering on instructions in an execution: synchronizes-with relation: Two instructions I and J in an execution are sync-with related if I is a release (like unlock(l)) and J is the next corresponding acquire (like lock(l)). Program-Order relation. HB order is the reflexive transitive closure of the union of program-order and sync-with relations. Two instructions in an execution are involved in a HB-race if they are conflicting accesses and are unordered by the the HB order.

slide-27
SLIDE 27

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Illustrating Happens-Before Race

main:

  • 1. x := 0;
  • 2. y := 0;
  • 3. spawn(t1);
  • 4. spawn(t2);

t1: t2:

  • 1. t := x;
  • 1. lock(l);
  • 2. lock(l);
  • 2. if (x < 10)
  • 3. if (x < 10)

3. x++; 4. x++;

  • 4. y++;
  • 5. y++;
  • 5. unlock(l);
  • 6. unlock(l);

x := 0 y := 0 spawn(t1) main: t1: t2: spawn(t2) lock(l) assume(x<10) x++ y++ unlock(l) t := x lock(l) assume(x<10)

slide-28
SLIDE 28

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Sync-CFG Analysis for HB-Race-Free Programs [De, D, Nasre 2011] Given a HB-Race-Free program Build a Sync-CFG for the program

Union of CFG’s of each thread May-Sync-With edges to conservatively capture sync-with relation.

Perform a Value-Set analysis. LFP values for a variable are guaranteed to be sound at points where the variable is owned by the thread.

slide-29
SLIDE 29

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Example Sync-CFG

  • 1. lock(l);
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);

t2:

  • 1. x := y := 0;
  • 2. spawn(t1);
  • 3. spawn(t2);

main: t1:

  • 0. t := 0;
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);
  • 1. lock(l);
slide-30
SLIDE 30

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Example Sync-CFG with Value-Set Analysis

  • 1. lock(l);
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);

t2:

  • 1. x := y := 0;
  • 2. spawn(t1);
  • 3. spawn(t2);

main: t1:

  • 0. t := 0;
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);
  • 1. lock(l);

0 ≤ x ≤ 10 0 ≤ y 0 ≤ x ≤ 10 0 ≤ y 0 ≤ x ≤ 10 0 ≤ y 0 ≤ x ≤ 10 0 ≤ y x = y = 0 x = y = 0

slide-31
SLIDE 31

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Soundess Claim and Proof Claim: Let P be a HB-race-free

  • program. Consider the final

data-flow facts in the Value-Set analysis for P. Suppose variable x is

  • wned by thread t at point N.

Consider an execution reaching N with x having value v. Then v belongs to the value set of x at N.

y := e(x) x := e’ lj lj + 1 N N′ ρ

slide-32
SLIDE 32

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Shortcomings and Extensions Can be imprecise due to following reasons:

No relational information (like x ≤ y). Spurious loops (y is unbounded).

Some extensions

Use regions of variables (like {x, y}) which are similarly protected, and compute a value-set for the region (can get x ≤ y). Define a relational sync-cfg based semantics which is sound and complete (Mukherjee et al 2017). This gives us a variety

  • f relational analyses.

Can handle programs with races (havoc reads of variables involved in a race)

slide-33
SLIDE 33

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Shortcomings and Extensions Can be imprecise due to following reasons:

No relational information (like x ≤ y). Spurious loops (y is unbounded).

Some extensions

Use regions of variables (like {x, y}) which are similarly protected, and compute a value-set for the region (can get x ≤ y). Define a relational sync-cfg based semantics which is sound and complete (Mukherjee et al 2017). This gives us a variety

  • f relational analyses.

Can handle programs with races (havoc reads of variables involved in a race)

How do we extend this Sync-CFG based analysis to programs with non-standard concurrency? What is the notion of a race, sync-with relation, HB order, etc?

slide-34
SLIDE 34

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Abstracted version of Send/ReceiveISR Methods

create(qrec_ISR); create(qsend); RxLock := 0; 5 4 3 1 2 6 7 wtorec := 0; len := 10; msgw := 0; wtosend := 0; 17 16 } 15 12 11 qsend: 10 18 if(msgw < len) { disableint; if(wtorec > 0) msgw++; wtorec−−; enableint; enableint; suspendsch; disableint; RxLock++; else { 48 47 46 if(msgw > 0) { 45 44 qrec_ISR: 49 msgw−−; if(RxLock = 0) { if(wtosend > 0) wtosend−−; } else RxLock++; } 19 20 21 22 23 24 25 26 27 14 13 29 28 enableint; wtosend++; RxLock := 0; 30 resumesch; } 31 31 disableint; while(RxLock > 1) { wtosend−−; } if(wtosend > 0) RxLock−−; 41 43 42 enableint; 31 main:

slide-35
SLIDE 35

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Disjoint blocks with locks

  • 1. lock(l);
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);

t2:

  • 1. x := y := 0;
  • 2. spawn(t1);
  • 3. spawn(t2);

main: t1:

  • 0. t := 0;
  • 2. if (x < 10)
  • 3. x++;
  • 4. y++;
  • 5. unlock(l);
  • 1. lock(l);
slide-36
SLIDE 36

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Disjoint Blocks

(a) (b) (c)

main: // begin t: // begin // end task: task: task: task:

(f) (d) (e)

task: task: task: ISR: // begin // end ISR: // begin // end ISR: // begin // end

create(t) suspendsch; resumesch; disableint; enableint suspendsch; suspendsch; resumesch; resumesch; enableint disableint; disableint; enableint disableint; enableint

slide-37
SLIDE 37

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Disjoint Blocks

// end

(f) (d) (e)

ISR: if(f = 0){ } } task: else { ISR: if(schsus = 0){ } } else { f := 1; f := 0; task:

(g) (h) create(t) resumesch; enableint resumesch; resumesch; suspendsch; resumesch;

slide-38
SLIDE 38

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Sync-CFG induced by FreeRTOS kernel

task: ISR: main:

slide-39
SLIDE 39

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Sync-CFG and the Value-Set analysis on it

17 16 } 15 12 11 qsend: 10 18 if(msgw < len) { disableint; if(wtorec > 0) msgw++; wtorec−−; enableint; enableint; suspendsch; disableint; RxLock++; else { 48 47 46 if(msgw > 0) { 45 44 qrec_ISR: 49 msgw−−; if(RxLock = 0) { if(wtosend > 0) wtosend−−; } else RxLock++; } create(qrec_ISR); create(qsend); RxLock := 0; 5 4 3 1 2 6 7 19 20 21 22 23 24 25 26 27 14 13 29 28 wtorec := 0; len := 10; msgw := 0; enableint; wtosend++; RxLock := 0; 30 resumesch; 31 disableint; while(RxLock > 1) { wtosend−−; } if(wtosend > 0) RxLock−−; 41 43 42 wtosend := 0; enableint; 31

msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 = RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 < RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 < RxLock 0 ≤ wtorec, 0 < wtosend msgw ≤ len, 0 < RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend msgw ≤ len, 0 ≤ RxLock 0 ≤ wtorec, 0 ≤ wtosend 0 = RxLock = msgw < len = 10

main:

slide-40
SLIDE 40

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Octagon/Polyhedral Analysis on FreeRTOS sync-CFG

Assertion Interval Region Analysis Analysis (Octagon/Polyhedra) xTickCount ≤ xNextTaskUnblockTime × √ head(pxDelayedTaskList) = xNextTaskUnblockTime × √ head(pxDelayedTaskList) ≥ TickCount × √ uxMessagesWaiting ≤ uxLength × √ uxMessagesWaiting ≥ 0 √ √ uxCurrentNumberOfTasks ≥ 0 √ √ lenpxReadyTasksLists ≥ 0 √ √ uxTopReadyPriority ≥ 0 √ √ lenpxDelayedTaskList ≥ 0 √ √ lenxPendingReadyList ≥ 0 √ √ lenxSuspendedTaskList ≥ 0 √ √ cRxLock ≥ -1 √ √ cTxLock ≥ -1 √ √ lenxTasksWaitingToSend ≥ 0 √ √ lenxTasksWaitingToReceive ≥ 0 √ √

slide-41
SLIDE 41

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Why a lock translation does not work Why not Translate interrupt-driven program P to classical lock-based PL, which captures interleaved executions of P. Now do race-detection and sync-CFG analysis on PL.

slide-42
SLIDE 42

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Races may not be preserved

main:

  • 1. x := y := t := 0;
  • 2. create(t1);
  • 3. create(t2);

t1: t2:

  • 4. x := x + 1;
  • 8. disableint;
  • 5. disableint;
  • 9. t := x;
  • 6. x := y;
  • 10. enableint;
  • 7. enableint;

Program P

main:

  • 1. x := y := t := 0;
  • 2. spawn(t1);
  • 3. spawn(t2);

t1: t2:

  • 4. lock(E)
  • 10. lock(E);
  • 5. x := x + 1;
  • 11. t := x;
  • 6. unlock(E)
  • 12. unlock(E);
  • 7. lock(E)
  • 8. x := y;
  • 9. unlock(E)

Execution preserving translation PL

slide-43
SLIDE 43

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Sync-CFG may be too imprecise

slide-44
SLIDE 44

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Our Translation Our approach can be viewed as giving a weak lock-based traslation P to PW which: Does not attempt to preserve execution semantics (allows more executions than original program) Preserves disjoint blocks, hence race-detection. Produces a lean sync-CFG with more precise data-flow facts.

slide-45
SLIDE 45

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Our “Weak” Translation

main:

  • 1. x := y := t := 0;
  • 2. create(t1);
  • 3. create(t2);

t1: t2:

  • 4. x := x + 1;
  • 8. disableint;
  • 5. disableint;
  • 9. t := x;
  • 6. x := y;
  • 10. enableint;
  • 7. enableint;

Program P

main:

  • 1. x := y := t := 0;
  • 2. spawn(t1);
  • 3. spawn(t2);

t1: t2:

  • 4. x := x + 1;
  • 8. lock(A);
  • 5. lock(A);
  • 9. t := x;
  • 6. x := y;
  • 10. unlock(A);
  • 7. unlock(A);

Lightweight translation PW

slide-46
SLIDE 46

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Sync-CFGs produced by the two translations

Translation PL

create(t2); create(t1); x := y := t := 0; 1 2 3 5 t1: 4 y := y+1; lock(E); lock(E); t2: 10 12 11 t := x; // assert(t<=1) unlock(E); 13 unlock(E); 6 unlock(E); x := y; 8 9 lock(E); 7

0 ≤ x, t 1 ≤ y

main:

0 ≤ x, y, t 0 ≤ x, y, t 0 ≤ x, y, t 0 ≤ x, y, t 0 ≤ x, y, t

Translation PW

create(t2); create(t1); x := y := t := 0; 1 2 3 6 5 t1: 4 y := y+1; 7 x := y; unlock(A); lock(A); t2: 8 10 9 t := x; // assert(t<=1) unlock(A); 11 lock(A); main:

x = y = t = 0 0 ≤ x, y, t ≤ 1 0 ≤ x, y, t ≤ 1 0 ≤ x, y, t ≤ 1 0 ≤ x, y, t ≤ 1

slide-47
SLIDE 47

Data Flow Analysis Concurrent Programs Race-Free Programs Sync-CFG Analysis Analysis

Conclusion and Future Directions Sync-CFG based analysis of race-free programs. Lays foundation for extending to other non-standard concurrency. Future directions:

Implement other analyses (Null dereference, points-to, shape analysis). Explore Sync-CFG as a proof technique for concurrent programs.