Code Aware Resource Scheduling

Transcription

1 Code Aware Resource Scheduling Marco Faella Fiat Slug with: Luca de Alfaro, UCSC Rupak Majumdar, UCLA Vishwanath Raman, UCSC Fridericus Dei Gratia Romanorum Imperator Semper Augustus 1

2 The problem mutex_lock(a) mutex_lock(b)... mutex_unlock(b) mutex_unlock(a) mutex_lock(b) mutex_lock(a)... mutex_unlock(a) mutex_unlock(b) resource manager scheduler OS 2

3 The problem mutex_lock(a) mutex_lock(b)... mutex_unlock(b) mutex_unlock(a) mutex_lock(b) mutex_lock(a)... mutex_unlock(a) mutex_unlock(b) instrumented program CYNTHESIS custom manager resource manager scheduler OS C compiler self-managed program 3

4 Outline Model defining deadlock Solution exact solution practical solution Tool 4

5 The literature Deadlock prevention/avoidance grant resources when it is safe to do so most work is off-line: prevention Flexible Manufacturing Systems processes as Petri Nets processes are terminating and/or deterministic Software Real-time scheduling of Java [Sifakis,Yovine, EMSOFT] 5

6 Assumptions Single processor Underlying fair scheduler One priority/no priority Threads are fixed and known in advance Threads block on mutexes and counting semaphores (resources) Threads are (possibly) non-terminating Threads are (possibly) non-deterministic 6

7 The model: sequential thread 0 w(a)!? w(b)! g(b)? r(b)! 5 6 r(a)! mutex_lock(a) mutex_lock(b)... mutex_unlock(b) mutex_unlock(a) 7

8 The model: non-determinism w(a)! 1? 2 r(a)! 0 w(b)! 4 g(b)? 5 r(b)! if (exp) { mutex_lock(a)... mutex_unlock(a) } else { mutex_lock(b)... mutex_unlock(b) } 3 6 8

9 The model: combining threads Take the asynchronous product of threads 0,3,7,9? 1,3,7,9 g(c)? r(b)! w(a)! 0,4,7,9 0,3,8,9 0,3,7,10 w(b)! 0,3,7,11 give lock a to thread 1 give lock c to thread 2 do not give any lock 9

10 More precisely... manager 0,3,7,9 scheduler? 1,3,7,9 g(c)? 0,4,7,9 r(b)! 0,3,8,9 thread non-determinism 0,3,7,9 w(a)! 0,3,7,10 w(b)! 0,3,7,11? g(c)? r(b)! 1,3,7,9 w(a)! 0,4,7,9 0,3,8,9 0,3,7,10 w(b)! 0,3,7,11 10

11 Our goal No deadlock + no starvation = progress a state with no successor only captures total deadlock a state where a thread has no successor wrong: sometimes threads are just waiting a trace where a thread is stuck goal: 11

12 Fair adversaries scheduler adversarial: no hope to win the game! (strongly) fair: if a thread is ready inf. oft., it is chosen inf. oft. thread non-determinism adversarial: loops might not be exited! (strongly) fair: if a branching point is visited inf. oft., both branches are taken inf. oft. amended goal: 12

13 Exact solution 2-player omega-regular game high complexity! (NP co-np) exponential in the number of processes replace fairness with randomization 13

14 Randomization 0,3,7,9 scheduler? 1,3,7,9 g(c)? 0,4,7,9 r(b)! thread non-determinism Theorem 1. Replacing the scheduler choice with a uniform distribution is safe. 0,3,8,9 w(a)! 0,3,7,10 w(b)! 0,3,7,11 14

15 Randomization 0,3,7,9 scheduler? 1,3,7,9 g(c)? 0,4,7,9 r(b)! thread non-determinism Theorem 1. Replacing the scheduler choice with a uniform distribution is safe. 0,3,8,9 w(a)! w(b)! Theorem 2. Replacing the thread non-determinism with a uniform distribution is not safe. 0,3,7,10 0,3,7,11 15

16 Theorem 2. Replacing the thread non-determinism with a uniform distribution is not safe. thread 1 thread 2 thread 3 r(b) g(b) g(c) r(c) r(d) g(d) g(e) r(e) g(c) r(a) r(a) r(a) r(a) g(e) 16

17 Theorem 2. Replacing the thread non-determinism with a uniform distribution is not safe. thread 1 thread 2 thread 3 r(b) g(b) g(c) r(c) r(d) g(d) g(e) r(e) g(c) r(a) r(a) r(a) r(a) g(e) c needs a e needs a Evil threads never release c and e at the same time. 17

18 Practical solution Theorem: We can check whether the approximation is safe in polynomial time Theorem: In particular, the approximation is safe if threads are periodically mutex free (usually the case) 18

19 Practical solution We obtain a Markov Decision Process, with a generalized Büchi objective: Solvable in polynomial time (quadratic) Winning strategies need memory or randomization [CdAH04] We extract the most general randomized winning strategy * Notice: * denies resources that are available and safe 19

20 Improving the manager Denying resources that are available and safe is bad! Is it necessary to do so? Theorem 3. Yes. Consider the strategy that denies locks only when there is no other choice. There is a game where such strategy is not winning. (hint: two threads exchange mutexes, leaving a third one starving) 20

21 Improving the manager Can we at least choose outputs less often? Yes! for mutex-only systems, include outputs when some thread holds mutexes for general systems, include outputs when a thread is blocked for any reason (no resource available, or giving resource is not safe) 21

22 The tool Cynthesis: parsing Handles C code, ecos or LegOs Path sensitive, data insensitive Handles contexts, without inlining Automatic, no annotations needed No pointers (work in progress), no lock arguments Ocaml, CIL 22

23 The tool Cynthesis: synthesis Enumerative representation Solves the simplified MDP Outputs winning strategy (BDD) A user-space run-time manager executes the strategy 23

24 Experiments Analyze an ad-hoc network protocol for LegoOs 5 threads, 15 locks 400k states 7 minutes to finish found and solved a deadlock run-time overhead: 5-10 microseconds 24

25 Future work Switch to symbolic representation Priorities Real-time scheduling QoS Acknowledgements Ian Dunbar Andrew Trapani 25