dynamic systems
play

Dynamic Systems DM519 Concurrent Programming 1 1 Repetition: - PowerPoint PPT Presentation

Dec 02, 2022 •256 likes •1.39k views

Chapter 9 Dynamic Systems DM519 Concurrent Programming 1 1 Repetition: Chapter 8 Model-Based Design Requirements Model Java DM519 Concurrent Programming 2 2 Repetition: Chapter 8 Model-Based Design Requirements Model Java DM519

  1. Golf Club Model Players: DM519 Concurrent Programming 12 12

  2. Golf Club Model Players: range R=1..N //request range DM519 Concurrent Programming 12 12

  3. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. DM519 Concurrent Programming 12 12

  4. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R] = (get[b]->put[b]->PLAYER[b]). DM519 Concurrent Programming 12 12

  5. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R] = (get[b]->put[b]->PLAYER[b]). set Experts = {alice,bob,chris} set Novices = {dave,eve} set Players = {Experts,Novices} DM519 Concurrent Programming 12 12

  6. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R] = (get[b]->put[b]->PLAYER[b]). set Experts = {alice,bob,chris} Players is the set Novices = {dave,eve} union of Experts set Players = {Experts,Novices} and Novices . DM519 Concurrent Programming 12 12

  7. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R] = (get[b]->put[b]->PLAYER[b]). set Experts = {alice,bob,chris} Players is the set Novices = {dave,eve} union of Experts set Players = {Experts,Novices} and Novices . HANDICAP = ({Novices.{need[3..N]},Experts.need[1..2]} -> HANDICAP ) +{Players.need[R]}. DM519 Concurrent Programming 12 12

  8. Golf Club Model Players: Fixed population of golfers: infinite range R=1..N //request range stream of requests. PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R] = (get[b]->put[b]->PLAYER[b]). set Experts = {alice,bob,chris} Players is the set Novices = {dave,eve} union of Experts set Players = {Experts,Novices} and Novices . HANDICAP = ({Novices.{need[3..N]},Experts.need[1..2]} -> HANDICAP Constraint on ) +{Players.need[R]}. need action of each player. DM519 Concurrent Programming 12 12

  9. Golf Club Model - Analysis GOLFCLUB ALLOCATOR Players:PLAYER HANDICAP get get Players.need need put put CARPARKCONTROL(N=4) = SPACES[N], SPACES[i:0..N] = (when(i>0) arrive->SPACES[i-1] ||GOLFCLUB =( Players:PLAYER ||Players::ALLOCATOR ||HANDICAP). DM519 Concurrent Programming 13 13

  10. Golf Club Model - Analysis GOLFCLUB ALLOCATOR Players:PLAYER HANDICAP get get Players.need need put put CARPARKCONTROL(N=4) = SPACES[N], SPACES[i:0..N] = (when(i>0) arrive->SPACES[i-1] ||GOLFCLUB =( Players:PLAYER Safety? Do players ||Players::ALLOCATOR ||HANDICAP). return the right number of balls? Liveness? Are players eventually allocated balls ? DM519 Concurrent Programming 13 13

  11. Golf Club Model - Liveness progress NOVICE = {Novices.get[R]} progress EXPERT = {Experts.get[R]} ||ProgressCheck = GOLFCLUB >>{Players.put[R]}. DM519 Concurrent Programming 14 14

  12. Golf Club Model - Liveness progress NOVICE = {Novices.get[R]} progress EXPERT = {Experts.get[R]} ||ProgressCheck = GOLFCLUB >>{Players.put[R]}. Progress violation: NOVICE Trace to terminal set of states: alice.need.2 bob.need.2 chris.need.2 chris.get.2 dave.need.5 eve.need.5 Cycle in terminal set: alice.get.2 alice.put.2 Actions in terminal set: {alice, bob, chris}.{get, put}[2] DM519 Concurrent Programming 14 14

  13. Golf Club Model - Liveness progress NOVICE = {Novices.get[R]} progress EXPERT = {Experts.get[R]} ||ProgressCheck = GOLFCLUB >>{Players.put[R]}. Progress violation: NOVICE Trace to terminal set of states: alice.need.2 bob.need.2 Novice players chris.need.2 dave and eve chris.get.2 suffer starvation. dave.need.5 They are eve.need.5 continually Cycle in terminal set: overtaken by alice.get.2 experts alice , alice.put.2 bob and chris. Actions in terminal set: {alice, bob, chris}.{get, put}[2] DM519 Concurrent Programming 14 14

  14. 9.3 Fair Allocation Allocation in arrival order, using tickets: const TM = 5 // maximum ticket range T = 1..TM // ticket values TICKET = NEXT[1], NEXT[t:T] = (ticket[t]->NEXT[t%TM+1]). DM519 Concurrent Programming 15 15

  15. 9.3 Fair Allocation Allocation in arrival order, using tickets: const TM = 5 // maximum ticket range T = 1..TM // ticket values TICKET = NEXT[1], NEXT[t:T] = (ticket[t]->NEXT[t%TM+1]). Players and Allocator: PLAYER = (need[b:R]->PLAYER[b]), PLAYER[b:R]= (ticket[t:T]->get[b][t]->put[b] ->PLAYER[b]). ALLOCATOR = BALL[N][1], BALL[b:B][t:T] = (when (b>0) get[i:1..b][t]->BALL[b-i][t%TM+1] |put[j:1..N] ->BALL[b+j][t] ). DM519 Concurrent Programming 15 15

  16. Fair Allocation - Analysis Ticketing increases the size of the model for analysis. We compensate by modifying the HANDICAP constraint: HANDICAP = ({Novices.{need[4]},Experts.need[1]}-> HANDICAP ) +{Players.need[R]}. Experts use 1 ball, Novices use 4 balls. ||GOLFCLUB =( Players:PLAYER ||Players::(ALLOCATOR||TICKET) ||HANDICAP). DM519 Concurrent Programming 16 16

  17. Fair Allocation - Analysis Ticketing increases the size of the model for analysis. We compensate by modifying the HANDICAP constraint: HANDICAP = ({Novices.{need[4]},Experts.need[1]}-> HANDICAP ) +{Players.need[R]}. Experts use 1 ball, Novices use 4 balls. ||GOLFCLUB =( Players:PLAYER ||Players::(ALLOCATOR||TICKET) ||HANDICAP). Safety? progress NOVICE = {Novices.get[R][T]} Liveness? progress EXPERT = {Experts.get[R][T]} DM519 Concurrent Programming 16 16

  18. 9.4 Revised Golf Club Program - FairAllocator Monitor DM519 Concurrent Programming 17 17

  19. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served public FairAllocator(int n) { available = n; } DM519 Concurrent Programming 17 17

  20. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served public FairAllocator(int n) { available = n; } synchronized public void get(int n) throws InterruptedException { DM519 Concurrent Programming 17 17

  21. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served public FairAllocator(int n) { available = n; } synchronized public void get(int n) throws InterruptedException { long myturn = turn; ++turn; DM519 Concurrent Programming 17 17

  22. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served Block calling public FairAllocator(int n) { available = n; } thread until synchronized public void get(int n) throws InterruptedException { sufficient balls long myturn = turn; ++turn; and next turn. while (n>available || myturn != next) wait(); DM519 Concurrent Programming 17 17

  23. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served Block calling public FairAllocator(int n) { available = n; } thread until synchronized public void get(int n) throws InterruptedException { sufficient balls long myturn = turn; ++turn; and next turn. while (n>available || myturn != next) wait(); ++next; available -= n; notifyAll(); } DM519 Concurrent Programming 17 17

  24. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served Block calling public FairAllocator(int n) { available = n; } thread until synchronized public void get(int n) throws InterruptedException { sufficient balls long myturn = turn; ++turn; and next turn. while (n>available || myturn != next) wait(); ++next; available -= n; notifyAll(); } synchronized public void put(int n) { available += n; notifyAll(); } } DM519 Concurrent Programming 17 17

  25. 9.4 Revised Golf Club Program - FairAllocator Monitor public class FairAllocator implements Allocator { private int available; private long turn = 0; // next ticket to be dispensed private long next = 0; // next ticket to be served Block calling public FairAllocator(int n) { available = n; } thread until synchronized public void get(int n) throws InterruptedException { sufficient balls long myturn = turn; ++turn; and next turn. while (n>available || myturn != next) wait(); ++next; available -= n; notifyAll(); } synchronized public void put(int n) { Why is it available += n; notifyAll(); necessary for } get to include } notifyAll()? DM519 Concurrent Programming 17 17

  26. Revised Golf Club Program - FairAllocator DM519 Concurrent Programming 18 18

  27. Revised Golf Club Program - FairAllocator Players g1 and h1 are waiting. Even though two balls are available, they cannot overtake player f4. DM519 Concurrent Programming 18 18

  28. Revised Golf Club Program - FairAllocator What happens Players g1 and h1 are waiting. Even though two if c , d and e all return their balls are available, they cannot overtake player f4. golf balls? DM519 Concurrent Programming 18 18

  29. 9.5 Bounded Allocation Allocation in arrival order is not efficient. A bounded allocation scheme allows experts to overtake novices but denies starvation by setting an upper bound on the number of times a novice can be overtaken. DM519 Concurrent Programming 19 19

  30. 9.5 Bounded Allocation Allocation in arrival order is not efficient. A bounded allocation scheme allows experts to overtake novices but denies starvation by setting an upper bound on the number of times a novice can be overtaken. We model players who have overtaken others as a set. DM519 Concurrent Programming 19 19

  31. 9.5 Bounded Allocation Allocation in arrival order is not efficient. A bounded allocation scheme allows experts to overtake novices but denies starvation by setting an upper bound on the number of times a novice can be overtaken. We model players who have overtaken others as a set. const False = 0 const True = 1 range Bool = 0..1 ELEMENT(Id=0) = IN[False], IN[b:Bool] = ( add[Id] -> IN[True] | remove[Id] -> IN[False] | contains[Id][b] -> IN[b] ). ||SET = (forall[i:T] (ELEMENT(i))). DM519 Concurrent Programming 19 19

  32. 9.5 Bounded Allocation Allocation in arrival order is not efficient. A bounded allocation scheme allows experts to overtake novices but denies starvation by setting an upper bound on the number of times a novice can be overtaken. We model players who have overtaken others as a set. const False = 0 const True = 1 range Bool = 0..1 A SET is ELEMENT(Id=0) = IN[False], modeled as IN[b:Bool] = ( add[Id] -> IN[True] the parallel | remove[Id] -> IN[False] composition | contains[Id][b] -> IN[b] of elements ). ||SET = (forall[i:T] (ELEMENT(i))). DM519 Concurrent Programming 19 19

  33. Bounded Allocation - Allocator Model DM519 Concurrent Programming 20 20

  34. Bounded Allocation - Allocator Model We model bounded overtaking using tickets, where ticket numbers indicate the order in which players make their requests. The allocator records which ticket number is next . DM519 Concurrent Programming 20 20

  35. Bounded Allocation - Allocator Model We model bounded overtaking using tickets, where ticket numbers indicate the order in which players make their requests. The allocator records which ticket number is next . Overtaking occurs when we allocate balls to a player whose turn - indicated by his/her ticket number – is subsequent to a waiting player with the next ticket. The overtaking player is added to the overtaking set, and a count ot is incremented to indicate the number of times next has been overtaken. DM519 Concurrent Programming 20 20

  36. Bounded Allocation - Allocator Model We model bounded overtaking using tickets, where ticket numbers indicate the order in which players make their requests. The allocator records which ticket number is next . Overtaking occurs when we allocate balls to a player whose turn - indicated by his/her ticket number – is subsequent to a waiting player with the next ticket. The overtaking player is added to the overtaking set, and a count ot is incremented to indicate the number of times next has been overtaken. When the count equals the bound, we allow allocation to the next player only. When allocation is made to the next player, we update next to indicate the next (waiting) player. We skip the ticket numbers of overtaking players who already received their allocation, remove each of these intervening players from the overtaking set and decrement the overtaking count ot accordingly. (This is achieved in the local process, WHILE, in the ALLOCATOR model.) DM519 Concurrent Programming 20 20

  37. Bounded Allocation - Allocator Model DM519 Concurrent Programming 21 21

  38. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = DM519 Concurrent Programming 21 21

  39. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> DM519 Concurrent Programming 21 21

  40. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> if (turn!=next) then (add[turn] -> BALL[b-i][next][ot+1]) else WHILE[b-i][next%TM+1][ot] DM519 Concurrent Programming 21 21

  41. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> if (turn!=next) then (add[turn] -> BALL[b-i][next][ot+1]) else WHILE[b-i][next%TM+1][ot] |when (b>0 && ot==Bd) get[i:1..b][next] -> WHILE[b-i][next%TM+1][ot] DM519 Concurrent Programming 21 21

  42. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> if (turn!=next) then (add[turn] -> BALL[b-i][next][ot+1]) else WHILE[b-i][next%TM+1][ot] |when (b>0 && ot==Bd) get[i:1..b][next] -> WHILE[b-i][next%TM+1][ot] |put[j:1..N] -> BALL[b+j][next][ot] ), DM519 Concurrent Programming 21 21

  43. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> if (turn!=next) then (add[turn] -> BALL[b-i][next][ot+1]) else WHILE[b-i][next%TM+1][ot] |when (b>0 && ot==Bd) get[i:1..b][next] -> WHILE[b-i][next%TM+1][ot] |put[j:1..N] -> BALL[b+j][next][ot] ), WHILE[b:B][next:T][ot:0..Bd] = (contains[next][yes:Bool] -> DM519 Concurrent Programming 21 21

  44. Bounded Allocation - Allocator Model //initially N balls, 1 is next, empty set ALLOCATOR = BALL[N][1][0], BALL[b:B][next:T][ot:0..Bd] = (when (b>0 && ot<Bd) get[i:1..b][turn:T] -> if (turn!=next) then (add[turn] -> BALL[b-i][next][ot+1]) else WHILE[b-i][next%TM+1][ot] |when (b>0 && ot==Bd) get[i:1..b][next] -> WHILE[b-i][next%TM+1][ot] |put[j:1..N] -> BALL[b+j][next][ot] ), WHILE[b:B][next:T][ot:0..Bd] = (contains[next][yes:Bool] -> if (yes) then (remove[next] -> WHILE[b][next%TM+1][ot-1]) else BALL[b][next][ot] ). DM519 Concurrent Programming 21 21

  45. Bounded Allocation - Allocator Model where const N = 5 // maximum #golf balls const Bd = 2 // bound on overtaking range B = 0..N // available range const TM = N + Bd // maximum ticket range T = 1..TM // ticket values DM519 Concurrent Programming 22 22

  46. Bounded Allocation - Allocator Model where const N = 5 // maximum #golf balls const Bd = 2 // bound on overtaking range B = 0..N // available range const TM = N + Bd // maximum ticket range T = 1..TM // ticket values ||GOLFCLUB = (Players:PLAYER || ALLOCATOR || TICKET || SET || HANDICAP )/ {Players.get/get, Players.put/put, Players.ticket/ticket}. DM519 Concurrent Programming 22 22

  47. Bounded Allocation - An Explanatory Trace eve.need.4 Experts Eve and Dave dave.need.4 chris.need.1 Novices Alice, Bob and Chris alice.need.1 Using bob.need.1 animation, we alice.ticket.1 alice.get.1.1 Alice gets 1 ball, ticket 1 can perform a contains.2.0 Ticket 2 is next scenario and bob.ticket.2 bob.get.1.2 Two allocated, three available produce a contains.3.0 Ticket 3 is next trace. dave.ticket.3 Dave needs four balls: waits chris.ticket.4 chris.get.1.4 Chris overtakes add.4 eve.ticket.5 Eve needs four balls: waits alice.put.1 alice.ticket.6 alice.get.1.6 Alice overtakes add.6 bob.put.1 bob.ticket.7 bob.get.1.7 Bob overtakes: bound reached add.7 DM519 Concurrent Programming 23 23

  48. Bounded Allocation - An Explanatory Trace chris.put.1 chris.ticket.8 Chris waits: three available alice.put.1 alice.ticket.1 Alice waits: four available dave.get.4.3 Dave gets four balls contains.4.1 remove intervening overtaker remove.4 contains.5.0 Ticket 5 (Eve) is next dave.put.4 dave.ticket.2 alice.get.1.1 Alice overtakes: bound reached add.1 bob.put.1 bob.ticket.3 eve.get.4.5 Eve gets four balls contains.6.1 remove intervening overtakers remove.6 contains.7.1 remove.7 contains.8.0 Ticket 8 (Chris) is next . . . DM519 Concurrent Programming 24 24

  49. Bounded Allocation - An Explanatory Trace chris.put.1 chris.ticket.8 Chris waits: three available alice.put.1 Exhaustive alice.ticket.1 Alice waits: four available dave.get.4.3 Dave gets four balls checking: contains.4.1 remove intervening overtaker remove.4 contains.5.0 Ticket 5 (Eve) is next Safety? dave.put.4 dave.ticket.2 alice.get.1.1 Alice overtakes: bound reached Liveness? add.1 bob.put.1 bob.ticket.3 Can we also eve.get.4.5 Eve gets four balls contains.6.1 remove intervening overtakers specify the remove.6 contains.7.1 bounded nature remove.7 contains.8.0 Ticket 8 (Chris) is next of this allocator . . . as a safety property? DM519 Concurrent Programming 24 24

  50. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. DM519 Concurrent Programming 25 25

  51. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = DM519 Concurrent Programming 25 25

  52. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in expressions or as parameter values must be prefixed with a single quote. DM519 Concurrent Programming 25 25

  53. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed with a single quote. DM519 Concurrent Programming 25 25

  54. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed WAITING[ticket:T][overtaken:0..Bd] = with a single quote. DM519 Concurrent Programming 25 25

  55. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed WAITING[ticket:T][overtaken:0..Bd] = with a single quote. ([P].get[b:R][ticket] -> BOUND DM519 Concurrent Programming 25 25

  56. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed WAITING[ticket:T][overtaken:0..Bd] = with a single quote. ([P].get[b:R][ticket] -> BOUND |{Players\{[P]}}.get[b:R][t:T] -> DM519 Concurrent Programming 25 25

  57. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed WAITING[ticket:T][overtaken:0..Bd] = with a single quote. ([P].get[b:R][ticket] -> BOUND |{Players\{[P]}}.get[b:R][t:T] -> if (t>ticket) then WAITING[ticket][overtaken+1] else WAITING[ticket][overtaken] DM519 Concurrent Programming 25 25

  58. Bounded Allocation – Safety Property For each player, check that he/she is not overtaken more than bound times. Overtaking is indicated by an allocation to another player whose ticket t lies between the turn of the player and the latest ticket. property BOUND(P='alice) = Action labels used in ([P].ticket[t:T] -> WAITING[t][0] expressions or as |[Players].get[R][T] -> BOUND parameter values ), must be prefixed WAITING[ticket:T][overtaken:0..Bd] = with a single quote. ([P].get[b:R][ticket] -> BOUND |{Players\{[P]}}.get[b:R][t:T] -> if (t>ticket) then WAITING[ticket][overtaken+1] else WAITING[ticket][overtaken] |Players.ticket[last:T] ->WAITING[ticket][overtaken] ). DM519 Concurrent Programming 25 25

  59. 9.6 Bounded Overtaking Allocator - Implementation Implementation of the BoundedOvertakingAllocator monitor follows the algorithm in the model. DM519 Concurrent Programming 26 26

  60. 9.6 Bounded Overtaking Allocator - Implementation Implementation of the BoundedOvertakingAllocator monitor follows the algorithm in the model. Novice player f4 has been overtaken by expert players g1 , h1 and i1 . Since the overtaking bound of three has been exceeded, players j1 and k1 are blocked although there are two golf balls available. DM519 Concurrent Programming 26 26

  61. 9.7 Master-Slave Program DM519 Concurrent Programming 27 27

  62. 9.7 Master-Slave Program A Master thread creates a Slave thread to perform some task (eg. I/O) and continues. DM519 Concurrent Programming 27 27

  63. 9.7 Master-Slave Program A Master thread creates a Slave thread to perform some task (eg. I/O) and continues. Later, the Master synchronizes with the Slave to collect the result. DM519 Concurrent Programming 27 27

  64. 9.7 Master-Slave Program A Master thread creates a Slave thread to perform some task (eg. I/O) and continues. Later, the Master synchronizes with the Slave to collect the result. How can we avoid busy waiting for the Master? DM519 Concurrent Programming 27 27

  65. 9.7 Master-Slave Program A Master thread creates a Slave thread to perform some task (eg. I/O) and continues. Later, the Master synchronizes with the Slave to collect the result. How can we avoid busy waiting for the Master? Java class Thread provides method join() which waits for the thread to die, i.e., by returning from run() or as a result of stop() . DM519 Concurrent Programming 27 27

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

Dynamic Systems Using R for Systems Understanding A Dynamic Approach Evolution of systems in

Dynamic Systems Using R for Systems Understanding A Dynamic Approach Evolution of systems in

Introduction Methods Lab model Ecosystem model Outlook Summary Dynamic Systems Using R for Systems Understanding A Dynamic Approach Evolution of systems in time (or / and space) Growth of organisms (and of my children), Thomas Petzoldt

538 views • 7 slides
Type Systems: Big Idea Static vs. Dynamic Typing Expressiveness (+ Dynamic) Dont have

Type Systems: Big Idea Static vs. Dynamic Typing Expressiveness (+ Dynamic) Dont have

Type Systems: Big Idea Static vs. Dynamic Typing Expressiveness (+ Dynamic) Dont have to worry about types (+ Dynamic) Dependent on input (- Dynamic) Runtime overhead (- Dynamic) Serve as documentation (+ Static)

572 views • 24 slides
Open, extensible dynamic programming systems or just how deep is the dynamic rabbit hole?

Open, extensible dynamic programming systems or just how deep is the dynamic rabbit hole?

DLS, Portland, 2006 10 23 Open, extensible dynamic programming systems or just how deep is the dynamic rabbit hole? Ian Piumarta Viewpoints Research Institute ian@squeakland.org dynamic dynamic? data? extending objects

719 views • 42 slides
SAIMENA PRESENTATION DYNAMIC POSITIONING SYSTEMS Introduction to Dynamic Positioning

SAIMENA PRESENTATION DYNAMIC POSITIONING SYSTEMS Introduction to Dynamic Positioning

SAIMENA PRESENTATION DYNAMIC POSITIONING SYSTEMS Introduction to Dynamic Positioning Dynamic Positioning Systems Dynamic Positioning Control Thruster Control Environmental Sensors Position Reference Sensors

685 views • 39 slides
1 Dynamic Systems Motions in the system depend on how the state of the system changes over

1 Dynamic Systems Motions in the system depend on how the state of the system changes over

Last time Introduction Fractals NetLogo Assignment 1 Assignment 2 7/11 - 06 Emergent Systems, Jonny Pettersson, UmU 1 Outline for today Nonlinear dynamic systems The Logistic map Strange attractors The Hnon

168 views • 12 slides
Dynamic Processors Demand Dynamic Operating Systems Sankaralingam Panneerselvam Michael M. Swift

Dynamic Processors Demand Dynamic Operating Systems Sankaralingam Panneerselvam Michael M. Swift

Dynamic Processors Demand Dynamic Operating Systems Sankaralingam Panneerselvam Michael M. Swift Computer Sciences Department University of Wisconsin, Madison, WI 1 HotPar 2010 Motivation Chip Multiprocessor Does not support well

378 views • 22 slides
Dynamic logics INF5140 Specification and Verification of Parallel Systems Dynamic logics,

Dynamic logics INF5140 Specification and Verification of Parallel Systems Dynamic logics,

Dynamic logics INF5140 Specification and Verification of Parallel Systems Dynamic logics, lecture 3 Spring 2015 February 24, 2015 2 / 21 Introduction Problem FOL is very (at leat relative) expressive but undecidable. Good for

380 views • 21 slides
Towards a Hybrid Dynamic Logic for Hybrid Dynamic Systems e Platzer 1 , 2 Andr 1 Carnegie

Towards a Hybrid Dynamic Logic for Hybrid Dynamic Systems e Platzer 1 , 2 Andr 1 Carnegie

Towards a Hybrid Dynamic Logic for Hybrid Dynamic Systems e Platzer 1 , 2 Andr 1 Carnegie Mellon University, Pittsburgh, PA, USA 2 University of Oldenburg, Department of Computing Science, Germany aplatzer@cs.cmu.edu LICS International

566 views • 37 slides
Modeling the Catchment Via Mixtures: an Uncertainty Framework for Dynamic Hydrologic Systems

Modeling the Catchment Via Mixtures: an Uncertainty Framework for Dynamic Hydrologic Systems

Modeling the Catchment Via Mixtures: an Uncertainty Framework for Dynamic Hydrologic Systems Dynamic Hydrologic Systems Lucy Marshall Assistant Professor of Watershed Analysis A i P f f W h d A l i Department of Land Resources and

580 views • 30 slides
Energy systems modelling Energy systems are Most decisions dynamic , non-linea r, are

Energy systems modelling Energy systems are Most decisions dynamic , non-linea r, are

Energy systems modelling Energy systems are Most decisions dynamic , non-linea r, are ill-informed. systemic and stochastic . Simulation supports multi-variate assessments. 1 Myriad supply side transition options strategic fossil

789 views • 33 slides
Modelling and Control of Dynamic Systems Course Organisation Sven Laur University of Tartu

Modelling and Control of Dynamic Systems Course Organisation Sven Laur University of Tartu

Modelling and Control of Dynamic Systems Course Organisation Sven Laur University of Tartu Course description The main focus is on the machine-learning methods: System identification with neural networks Control of dynamic systems

303 views • 9 slides
Dynamic Evolution of .NET Systems Jason Hallstrom, Mariana Barca, William Leal, Anish Arora The

Dynamic Evolution of .NET Systems Jason Hallstrom, Mariana Barca, William Leal, Anish Arora The

Dynamic Evolution of .NET Systems Jason Hallstrom, Mariana Barca, William Leal, Anish Arora The Ohio State University The Dynamic Reconfiguration Premise Systems evolve over time. System mission changes. Improved implementations are

459 views • 13 slides
(Belief) Dynamic Doxastic Differential Dynamic Logic (d4L) for Belief-Aware Cyber Physical

(Belief) Dynamic Doxastic Differential Dynamic Logic (d4L) for Belief-Aware Cyber Physical

(Belief) Dynamic Doxastic Differential Dynamic Logic (d4L) for Belief-Aware Cyber Physical Systems Joo G. Martins 1,2 , Andr Platzer 2 , Joo Leite 1 1 2 1 Cyber-Physical Systems (CPS) Continuous movement Discrete control 2

971 views • 47 slides
1 Static Equilibrium From Static Eq. to Dynamic Eq. System of mass points Static

1 Static Equilibrium From Static Eq. to Dynamic Eq. System of mass points Static

Static/ Dynamic Deformation I ntroduction to Static deformation Dynamic deformation Static/ Dynamic Deformation with Mass-Spring Systems undeformed shape f internal + = f inertia = 0 f external Min Gyu Choi deformed

426 views • 4 slides
AN INTEGRATED UNDERGRADUATE DYNAMIC SYSTEMS TEACHING METHODOLOGY UTILIZING ANALYTICAL AND

AN INTEGRATED UNDERGRADUATE DYNAMIC SYSTEMS TEACHING METHODOLOGY UTILIZING ANALYTICAL AND

ASEE Conference June 2007 Hawaii AN INTEGRATED UNDERGRADUATE DYNAMIC SYSTEMS TEACHING METHODOLOGY UTILIZING ANALYTICAL AND EXPERIMENTAL APPROACHES FIRST &amp; SECOND ORDER SYSTEMS DIGITIAL DATA ACQUISITION SIGNAL CONDITIONER RISE

649 views • 22 slides
Numerical method: systems 1 Equipment performance: dynamic and non-linear Condenser temp.: 20

Numerical method: systems 1 Equipment performance: dynamic and non-linear Condenser temp.: 20

Numerical method: systems 1 Equipment performance: dynamic and non-linear Condenser temp.: 20 C, 30 C, 40 C, 50 C heat pump boiler gas turbine fuel cell wind turbine photovoltaics Issues: dynamic response, conditions monitoring, hybrid

363 views • 21 slides
6/28/2016 Land Trust Standards &amp; Practices on Conservation Easements Standards 8, 9, 10

6/28/2016 Land Trust Standards &amp; Practices on Conservation Easements Standards 8, 9, 10

6/28/2016 Land Trust Standards &amp; Practices on Conservation Easements Standards 8, 9, 10 (drafting) &amp; 11 (stewardship) Good conservation: deals and deeds Enforceable conditions: drafting and baselines Defense: Good monitoring

183 views • 3 slides
Community Workshop 4 October 2017 Agenda Workshop purpose Current state Study

Community Workshop 4 October 2017 Agenda Workshop purpose Current state Study

Community Workshop 4 October 2017 Agenda Workshop purpose Current state Study area, demographics, existing facilities Some research Engagement studies Discussion Parameters, feedback Next steps Purpose

356 views • 31 slides
Patent Law Prof. Roger Ford Monday, November 6, 2017 Class 19 Infringement I: claim

Patent Law Prof. Roger Ford Monday, November 6, 2017 Class 19 Infringement I: claim

Patent Law Prof. Roger Ford Monday, November 6, 2017 Class 19 Infringement I: claim construction &amp; literal infringement Recap Recap Utility overview Operability Beneficial or moral utility Practical or specific utility

842 views • 34 slides
NSP O NSP Open Forum pen Forum Question and Answers th 2014 June 5 June 5 , 2014 2:00 PM ET

NSP O NSP Open Forum pen Forum Question and Answers th 2014 June 5 June 5 , 2014 2:00 PM ET

U.S. Department of Housing and Urban Development NSP O NSP Open Forum pen Forum Question and Answers th 2014 June 5 June 5 , 2014 2:00 PM ET Community Planning and Development Moderators and Q &amp; A Format Moderators and Q &amp; A Format

289 views • 7 slides
CSSV: Towards a Realistic Tool for Statically Detecting All Buffer Overflows in C An article by

CSSV: Towards a Realistic Tool for Statically Detecting All Buffer Overflows in C An article by

General Presentation In-Depth Analysis Results and Perspectives CSSV: Towards a Realistic Tool for Statically Detecting All Buffer Overflows in C An article by Nurit Dor, Michael Rodeh and Mooly Sagiv Presentation by Antoine Amarilli

650 views • 32 slides
Developing Shared Governance Increasing the Facultys Role in Academic Decision Making 1

Developing Shared Governance Increasing the Facultys Role in Academic Decision Making 1

Developing Shared Governance Increasing the Facultys Role in Academic Decision Making 1 Hans-Joerg Tiede, Presenter Illinois Wesleyan University Chair, AAUP Assembly of State Conferences 2 AAUP Mission To advance academic freedom

607 views • 35 slides
Multisites and Platforms and Governance - Oh My!

Multisites and Platforms and Governance - Oh My!

Multisites and Platforms and Governance - Oh My!

608 views • 21 slides
OMB A-123 Update CIGIE/GAO 2015 Financial Statement Audit Conference April 28, 2015 Mike

OMB A-123 Update CIGIE/GAO 2015 Financial Statement Audit Conference April 28, 2015 Mike

OMB A-123 Update CIGIE/GAO 2015 Financial Statement Audit Conference April 28, 2015 Mike Wetklow Office of Federal Financial Management Office of Management and Budget 1 A-123 History 1981 OMB First Issued Circular No. A-123,

443 views • 12 slides

More recommend