Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Prüfungen im Bachelor-Studium (1. - 5. Semester) » pfp » Aufgabe 1 (Übersicht)
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung | ||
pruefungen:bachelor:pfp:loesungss15 [22.07.2016 12:41] – V. a. Aufgabe 2 an Klausurbesprechung mit Tutoren heute angepasst Marcel[Inf] | pruefungen:bachelor:pfp:loesungss15 [02.08.2019 08:30] (aktuell) – Destranix | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Aufgabe 1 ====== | ====== Aufgabe 1 ====== | ||
* a) Sequentieller Umstieg, Beschränkung der Parallelität. | * a) Sequentieller Umstieg, Beschränkung der Parallelität. | ||
- | * b) Das Schalten einer Transition erfolgt atomar. | + | * b) Das Schalten einer Transition erfolgt atomar. |
* c) Die parallale Effizienz ist 2. Der Speedup ist 16. | * c) Die parallale Effizienz ist 2. Der Speedup ist 16. | ||
Zeile 41: | Zeile 41: | ||
* a) {{: | * a) {{: | ||
- | * b) Ein Pfeil von Q zu t1 (Gewicht 1) und ein Pfeil von t2 zu Q (Gewicht 2). | + | * b) Ein Pfeil von Q zu t1 (Gewicht 1) und ein Pfeil von t2 zu Q (Gewicht 2). Desweiteren muss noch verhindert werden, dass t3 schalten und somit unendlich viele Marken generieren kann. Dazu ist z.B. eine Kante von Q zu t3 mit dem Gewicht 3 nötig. |
====== Aufgabe 4====== | ====== Aufgabe 4====== | ||
* a) | * a) | ||
- | * Zeile 27: Ja, weil AtomicInteger intern synchronisiert ist. | + | * Zeile 27: Nein, weil AtomicInteger |
* Zeile 34: Ja, weil jeder Thread nur die lokale Variable modifiziert und synchronized(this) eh sinnlos ist. | * Zeile 34: Ja, weil jeder Thread nur die lokale Variable modifiziert und synchronized(this) eh sinnlos ist. | ||
* Zeile 38: Nein, globalHits ist allen Threads gemein => sonst Lesen-Ändern-Schreiben-Wettlaufsituation. | * Zeile 38: Nein, globalHits ist allen Threads gemein => sonst Lesen-Ändern-Schreiben-Wettlaufsituation. | ||
* b) | * b) | ||
* 14/46: Nein, weil i in #47 zur Berechnung benötigt wird. D.h. man benötigt sowohl Datensichtbarkeit (wäre mit volatile auch möglich) als auch zeitliche Synchronisation (nur dank barrier.await() hier möglich). | * 14/46: Nein, weil i in #47 zur Berechnung benötigt wird. D.h. man benötigt sowohl Datensichtbarkeit (wäre mit volatile auch möglich) als auch zeitliche Synchronisation (nur dank barrier.await() hier möglich). | ||
- | * 19/49: Ja, da v eine volatile Referenz ist und Spin (= aktives Warten) existent. | + | * 19/49: Ja, da v eine volatile Referenz ist und Spin (= aktives Warten) existent. |
* 22/52: Laut Tutor soll man jede Barriere einzeln betrachten. Wir gehen also davon aus, dass die Barriere 19/49 immer noch existent ist. Dann gilt k=-1 sicher in Zeile 50 in Thread 3. Es ist jedoch nicht garantiert, dass wir jemals den neuen Wert aus Zeile 21 in Thread 3 auslesen werden, da k nicht volatile ist. Daher entweder k volatile deklarieren oder die Barriere dort lassen (=> Antwort " | * 22/52: Laut Tutor soll man jede Barriere einzeln betrachten. Wir gehen also davon aus, dass die Barriere 19/49 immer noch existent ist. Dann gilt k=-1 sicher in Zeile 50 in Thread 3. Es ist jedoch nicht garantiert, dass wir jemals den neuen Wert aus Zeile 21 in Thread 3 auslesen werden, da k nicht volatile ist. Daher entweder k volatile deklarieren oder die Barriere dort lassen (=> Antwort " | ||
* 22/52: Begründung unter Annahme, dass 19/49 bereits gestrichen wurde: Nein, denn in Thread 3 könnte k=0 (Default-Wert bei Instanzinitialisierung der " | * 22/52: Begründung unter Annahme, dass 19/49 bereits gestrichen wurde: Nein, denn in Thread 3 könnte k=0 (Default-Wert bei Instanzinitialisierung der " | ||
Zeile 67: | Zeile 67: | ||
}) | }) | ||
- | def game: Field => Stream[Field] = f => f #:: game(tick8f)) | + | def game: Field => Stream[Field] = f => f #:: game(tick(f)) |
</ | </ | ||
====== Aufgabe 6 ====== | ====== Aufgabe 6 ====== |