Advertisement
Guest User

Untitled

a guest
May 29th, 2015
236
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.93 KB | None | 0 0
  1. A1
  2. (a)
  3. Die Prozesse müssen sich im gegebenen Schema stets abwechseln. Stürzt z.B P1 in remainderSection(P1) ab, so kann P0 noch ein mal durchgeführt werden, danach aber nie wieder, da P1 ausgeführt werden müsste, um turn wieder auf 0 zu setzen. Damit ist die Bedingung "Progress" verletzt, da in diesem Szenario P0 nicht wieder ausgeführt wird, aber dies nicht durch die Bevorzugung anderer Prozesse zustandekommt.
  4.  
  5. (b)
  6. Dieses Verfahren garantiert nicht die Bedingung "Mutual exclusion", was an folgendem Beispiel ersichtlich wird:
  7. Es wird zunächst P0 ausgeführt, bis turn = 1 gesetzt wird und wird dann unterbrochen. Dann wird P1 ausgeführt, bis turn = 0 gesetzt wird. Nun wird wieder P0 ausgeführt, aber in remainderSection() wieder unterbrochen (d.h. alive[0] = 0) und P1 wieder fortgesetzt und erreicht den kritischen Bereich (da alive[0] = 0) und wird unterbrochen (weiterhin ist turn = 0). Nun wird P0 wieder ausgeführt, und da turn = 0 ist, darf P0 auch den kritischen Bereich betreten, obwohl P1 ebenfalls darin ist.
  8.  
  9. (c)
  10. Hier wird "Bounded Waiting" verletzt. Es ist nämlich nicht garantiert, dass ein Prozess jemals den kritischen Bereich betreten darf. Dazu ein Beispiel: P0 wird immer nach dem Setzen des Locks unterbrochen und P1 ausgeführt, danach wieder P0 bis zum Erneuten Setzen des Locks. Dann kann P1 nie den kritischen Bereich betreten, P0 aber beliebig oft. Somit ist es nicht garantiert, dass P1 nur endlich lange bis zur Ausführung des kritischen Bereiches warten muss.
  11.  
  12. A2
  13. (a)
  14. Es liegt ein möglicher Deadlock vor, denn der Verbraucher kann den kritischen Bereich sperren, obwohl er nichts tun kann, da N = 0 vorliegt. Nun kann aber auch kein Erzeuger mehr in den kritischen Bereich, da ein Verbraucher diesen sperrt, d.h. es kann kein Gut für den Verbrauch erzeugt werden, sodass der Verbraucher den kritischen Bereich nie wieder verlässt. Dies kann behoben weden, indem die Reihenfolge der wait()-Befehle des Verbrauchers getauscht werden, denn dann betritt dieser nur den kritischen Bereich, wenn auch etwas zum Verbrauch vorhanden ist und er folglich den kritischen Bereich auch wieder verlässt.
  15.  
  16. (b)
  17. queue q_einw;
  18. int automat_lock = 0; //Test-Set-Lock-Variable für Synchronisierung des Ticket-Ziehens
  19. int m; //Anzahl der Schalter
  20. init(M, m); //Erstelle Zählsemaphore für die Schalter
  21.  
  22.  
  23. EINWOHNER
  24.  
  25. pid = getpid();
  26. while(tsl(&automat_lock) != 0){
  27. noop;
  28. }
  29. pushback(q_einw,pid);
  30. automat_lock = 0;
  31. sleep();
  32. macheAmtZeug();
  33. signal(M);
  34.  
  35. AUFRUFANLAGE
  36.  
  37. while(true){ //Anders als normale Ämter arbeiten wir IMMER
  38. wait(M); //Warte auf freien Schalter
  39. if(size(q_einw) > 0){
  40. //Falls noch Einwohner abzuarbeiten sind, machen wir das
  41. next = popfront(q_einw);
  42. wakeup(next);
  43. }
  44. }
  45.  
  46. (c)
  47. queue q_einw;
  48. queue q_mutter;
  49. int automat_lock = 0; //Test-Set-Lock-Variable für Synchronisierung des Ticket-Ziehens
  50. int automat_mutter_lock = 0;
  51. int m; //Anzahl der Schalter
  52. init(M, m); //Erstelle Zählsemaphore für die Schalter
  53.  
  54. MUTTER m. N.
  55.  
  56. pid = getpid();
  57. while(tsl(&automat_mutter_lock) != 0){
  58. noop;
  59. }
  60. pushback(q_mutter,pid);
  61. automat_mutter_lock = 0;
  62. sleep();
  63. macheAmtZeug();
  64. signal(M);
  65.  
  66. EINWOHNER (KEINE MUTTER)
  67.  
  68. pid = getpid();
  69. while(tsl(&automat_lock) != 0){
  70. noop;
  71. }
  72. pushback(q_einw,pid);
  73. automat_lock = 0;
  74. sleep();
  75. macheAmtZeug();
  76. signal(M);
  77.  
  78. AUFRUFANLAGE
  79.  
  80. while(true){ //Anders als normale Ämter arbeiten wir IMMER
  81. wait(M); //Warte auf freien Schalter
  82. if(size(q_mutter) > 0){
  83. //Falls noch Mutternde abzuarbeiten sind, machen wir das
  84. next = popfront(q_mutter);
  85. wakeup(next);
  86. } else if(size(q_einw) > 0){
  87. //Falls noch Einwohner abzuarbeiten sind, machen wir das
  88. next = popfront(q_einw);
  89. wakeup(next);
  90. }
  91. }
  92.  
  93. (d)
  94. Durch den Einsatz von Zählsemaphoren mit assoziierten Queues müssen die Semaphore und die Queue aus (b) nicht einzeln verwaltet werden, sondern können direkt über die jeweiligen Befehle zugleich gemanagt werden (was potentielle Fehlerquellen und Implementierungsaufwand verringert).
  95.  
  96. A3
  97. (a)
  98. Semaphore sind Konstrukte, die i.d.R. aus einer int-Variable sowie gewissen Funktionen, die diese Variable verändern/ausgeben bestehen. Dabei steht die int-Variable für die Anzahl der verfügbaren Betriebsmittel eines gewissen Typs; die Funktionen repräsentieren das Reservieren/Freigeben dieser Mittel, sodass Semaphore zur Synchronisierung des Zugriffs auf Betriebsmittel genutzt werden.
  99.  
  100. (b)
  101. init() - erzeugt eine neue Semaphore und definiert die Anzahl der zur Verfügung stehenden Betriebsmittel durch das übergebene Argument
  102. wait() - testet, ob Betriebsmittel vorhanden sind und wartet ggf. ab, bis dies der Fall ist.
  103. signal() - erhöht den Wert der Semaphore und signalisiert so das Freigeben eines Betriebsmittels
  104. destroy() - Vernichtet die Semaphore (Ohne Warten auf die Freigabe durch die benutzenden Prozesse, was zu undefiniertem Verhalten führen kann!)
  105.  
  106. A4
  107. siehe Sourcefiles
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement