Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Prüfungen im Bachelor-Studium (1. - 5. Semester) » pfp » Lösungsvorschlag   (Übersicht)

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
pruefungen:bachelor:pfp:loesungss12 [24.07.2015 09:13] – ThiloKpruefungen:bachelor:pfp:loesungss12 [03.08.2019 18:37] (aktuell) – mrpwner
Zeile 9: Zeile 9:
   * richtig   * richtig
  
-**c)** 1+**c)** Zählt man die Startbelegung S auch zum Petri-Netz, so ist ∞ die richtige Antwort, sonst 1
  
 +**d)**
 +
 +**e)**
 +
 +**f)**
  
 ==== Aufgabe 2 (Petri-Netze) ==== ==== Aufgabe 2 (Petri-Netze) ====
Zeile 19: Zeile 24:
  
    M:     M: 
-    0   0   0   0   1+    0   0   0   0   0
     2   0  -1  -1   0     2   0  -1  -1   0
     0   1  -1   0   0     0   1  -1   0   0
    -1  -1   0   0   2    -1  -1   0   0   2
     0   0   3   1  -4     0   0   3   1  -4
 +    
  
-Petri-Netz ist lebendig, da Summe aller Marken bei t0 -> t2 -> t3 -> t4 -> t1 unverändert bleibt. Alle Transitionen können immer wieder schalten!+Petri-Netz ist nicht lebendig, da durch t0 -> t3 -> t3 ein Deadlock entsteht!
  
 **b)** **b)**
Zeile 33: Zeile 39:
 ==== Aufgabe 4 (Lambda-Kalkül) ==== ==== Aufgabe 4 (Lambda-Kalkül) ====
 <note>Haskell und Lambda-Kalkül werden nicht mehr gelehrt!</note> <note>Haskell und Lambda-Kalkül werden nicht mehr gelehrt!</note>
 +
 +==== Aufgabe 5 (Java - Zeigerverdopplung) ====
 +
 +<code java>
 +import java.util.concurrent.*;
 +public class PointerDoubling {
 + private static int[] next ;
 + private static int[] rank;
 + private static CyclicBarrier outer;
 + private static CyclicBarrier inner;
 + public static int[] calculateRanks (int [] next) 
 + throws InterruptedException, BrokenBarrierException {
 + PointerDoubling.next = next;
 + rank = new int[next.length];
 + outer = new CyclicBarrier(next.length + 1);
 + inner = new CyclicBarrier(next.length);
 + // TODO: 1
 + Thread[] threads = new Thread[next.length];
 + for (int i = 0; i < next.length; i++) {
 + threads[i] = new Worker(i);
 + threads[i].start();
 + }
 + outer.await();
 + return rank;
 + }
 +
 + public static class Worker extends Thread {
 + private final int index;
 + public Worker (int index) {
 + this.index = index;
 + }
 +
 + public void run () {
 + try {
 + // TODO: 2
 + if (next[index] == -1) {
 + rank[index] = 1;
 + }
 + // TODO: 4
 + // inner.await(); -- not needed // EDIT: Wieso nicht? Die Threads nutzen eine gemeinsame Datenstruktur, und wenn einer etwas daran ändert, muss eine Sichtbarkeitssynchronisation vorgenommen werden, die mit einer Barrier möglich ist. Sonst würden andere Threads bereits den unteren Code ausfuehren, ohne die Garantie, dass für irgendeinen das Ende (-1) sichtbar ist. Lasse mich gerne korrigieren, falls ich falsch liege.
 + int distance = 1 ;
 + while (distance < next.length) {
 + int rankOfNext = 0;
 + int nextOfNext = 0;
 + if (next[index] > 0) {
 + rankOfNext = rank[next[index]];
 + nextOfNext = next[next[index]];
 + }
 + // TODO: 4
 + // inner.await(); -- not needed
 + // TODO: 3
 + if (rankOfNext != 0) {
 + rank[index] = rankOfNext + distance;
 + next[index] = nextOfNext;
 + } else {
 + next[index] = nextOfNext;
 + }
 + // TODO: 4
 + inner.await();
 + distance *= 2;
 + } // END OF while
 + outer.await();
 + } catch (Exception e) {
 + e.printStackTrace();
 + }
 + } // END OF run
 + } // END OF Worker
 +} // END OF PointerDoubling
 +</code>
 +
 +<note>Vermutlich reicht das inner.await() am Ende der While-Schleife. Als ich weiter oben ein <code>if (index == 0) { Thread.sleep(1000); }</code> stehen hatte, lieferte der Code immer noch das richtige Ergebnis. Bin mir da aber nicht hundert Pro sicher  :-P</note>
 +
 +==== Aufgabe 6 (Sichtbarkeit und Wettlaufsituation) ====
 +
 +**a)**
 +Vier, Rechenzeit wird Threads zufällig zugeteilt, weshalb die Reihenfolge von Inkrementieren und Schreiben nicht geklärt werden kann.
 +
 +**b)**
 +digits[2] == 0 | 1 \\
 +Auch hier kann nicht vorausgesagt werden, ob erst inkrementiert oder erst geschrieben wird. Sicher ist jedoch, dass sich die Threads keine Kopie der Variablen halten und somit immer auf den zuletzt geschriebenen Wert zugreifen!
 +
 +**c)**
 +digits[3] == 9 \\
 +Da Thread2 an barrier auf das Schreiben von Thread1 wartet, wird gewährleistet, dass sicher der zuvor gesetzte Wert geschrieben wird.
 +
 +**d)**
 +Alle Werte zwischen 2 und 8 sind möglich.
 +
 +**e)**
 +digits[5] == 5 | 7 \\
 +Da nicht geklärt ist, welcher Thread nach barrier.await() zuerst Rechenzeit zugeteilt bekommt, entsteht eine Wettlaufsituation um dv5.