1 / 16

Monitor

Monitor. Giving credit where it is due: The lecture notes are borrowed from Dr. I-Ling Yen at University of Texas at Dallas I have modified them and added new slides. Problems with Semaphores.

edan-wade
Download Presentation

Monitor

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Monitor • Giving credit where it is due: • The lecture notes are borrowed from Dr. I-Ling Yen at University of Texas at Dallas • I have modified them and added new slides

  2. Problems with Semaphores • Correct use of semaphore operations may not be easy, since they may be scattered throughout a program:

  3. Monitors • A high-level abstraction that provides equivalent functionality to that of semaphores and that is easier to control • The monitor construct has been implemented in a number of programming languages and as a program library • A programmer does not need to manually write the entire synchronization code

  4. Monitors monitor monitor-name { // shared variables declarations procedure P1 (…) { …. } … procedure Pn (…) {……} Initialization code (….) { … } … }

  5. Monitor • Protect shared objects within an abstraction • Provide encapsulation • Accesses to a shared object is confined within a monitor • Provide mutual exclusive accesses • No two process can be active at the same time within a monitor monitor Monitor already provides lock box and corresponding control mechanism

  6. Shared Device Program with Monitor • N devices in the system • Use any of them as long as it is free monitor mutex_devices: free: array [0..N–1] ofboolean; -- initialized to true int acquire () { fori := 0 to N–1 do if (free[i]) then { free[i] := false; return (i); } else return (–1); } void release (index: integer) { free[index] := true; }

  7. Synchronization within a Hoare-style Monitor • Monitor guarantees mutual exclusive accesses • May still need synchronization • Monitor also provides condition variables • To achieve conditional wait and support synchronization • Associated with each condition variable • A condition queue • The wait and signal functions • If wait inside a monitor • Same as wait inside a lockbox protected by a semaphore (mutex) • Has potential of deadlock • Monitor provides mechanism to counter it • Monitor guarantees mutual exclusive accesses • May still need synchronization • E.g., shared device problem • wait for device to become available • E.g., bounded buffer problem • wait for buffer to become full/empty

  8. Synchronization within a Hoare-style Monitor condition queue monitor x y condition variable

  9. Bounded Buffer Problem with a Hoare-style Monitor monitor bounded_buffer buffer: array [0..n-1] of item; in, out, counter: integer := 0; empty, full: condition; functiondeposit (item) functionremove (&item) {  if (counter = n) then {  if (counter = 0) then full.wait; empty.wait;     buffer[in] := item;     item := buffer[out]; in := (in+1) % n; out := (out+1) % n;     counter := counter + 1;      counter := counter – 1;     empty.signal;     full.signal; } }

  10. Bounded Buffer Problem with a Hoare-style Monitor Producer process: repeatproduce item    deposit (item); untilfalse; Consumer process: repeat    remove (item);     consume item; untilfalse;

  11. Bounded Buffer Problem with a Hoare-style Monitor (Signal-and-Wait Discipline) functiondeposit (item) {  if (counter = n) then full.wait;     buffer[in] := item; in := (in+1) % n;     counter := counter + 1;     empty.signal; } functionremove (&item) { if (counter = 0) then empty.wait;     item := buffer[out]; out := (out+1) % n;    counter := counter – 1;     full.signal; } condition queue monitor full empty

  12. Bounded Buffer Problem with a Hoare-style Monitor (Signal-and-Wait Discipline) functionfun1 () {  … empty.signal;     …} • function fun2 () { • … •     empty.wait; • …} • A process signals and then must be blocked; signal-and-wait • Process scheduling associated with a signal must be perfectly reliable condition queue monitor full empty

  13. Bounded Buffer Problem with a Hoare-style Monitor (Signal-and-Wait Discipline) functiondeposit (item) {  if (counter = n) then full.wait;     buffer[in] := item; in := (in+1) % n;     counter := counter + 1;     empty.signal; } functionremove (&item) { if (counter = 0) then empty.wait;     item := buffer[out]; out := (out+1) % n;    counter := counter – 1;     full.signal; } condition queue monitor full empty

  14. Bounded Buffer Problem with a Mesa Monitor (Signal-and-Continue Discipline) monitor bounded_buffer buffer: array [0..n-1] of item; in, out, counter: integer := 0; empty, full: condition; functiondeposit (item) functionremove (&item) {  while (counter = n) then {  while (counter = 0) then full.wait; empty.wait;     buffer[in] := item;     item := buffer[out]; in := (in+1) % n; out := (out+1) % n;     counter := counter + 1;      counter := counter – 1;     empty.notify;     full.notify; } }

  15. Bounded Buffer Problem with a Mesa Monitor (Signal-and-Continue Discipline) functiondeposit (item) {  while (counter = n) then full.wait;     buffer[in] := item; in := (in+1) % n;     counter := counter + 1;     empty.notify; } functionremove (&item) { while (counter = 0) then empty.wait;     item := buffer[out]; out := (out+1) % n;    counter := counter – 1;     full.notify; } condition queue monitor full  empty watchdog timer

  16. Monitor • Monitor provides encapsulation • Accesses to a shared object is confined within a monitor • Easier to debug the code • E.g., bounded buffer problem, deposit & remove functions • What should be encapsulated? • Too much  reduce concurrency • Some part of the code that can be executed concurrently, if encapsulated in the monitor, can cause reduced concurrency

More Related