a) Richtig (Kommentar hierzu: Zudem bei Volatile lesen und schreiben jeweils Atomar, Ändern hingegen nicht.) b) Richtig c) Falsch (Fixed -> Feste Anzahl an Threads.) d) Falsch (Bei Cyclicbarrier erfolgt Sichtbarkeitssynchronisation) e) Falsch (Datenparallel! Taskparallel wäre beispielsweise Pipeline) f) 42s (1x18s + (5-1)x6s) g) Kein Klausurstoff mehr! h) Falsch. (Sie wird mit f((5, 6)) aufgerufen)(Oder Funktion zu Int => Int => Int umschreiben)
(Das originale Word-Dokument zum Bild habe ich auch hier in denselben Namensraum zwecks etwaigen Änderungen hochgeladen.)
S = ( 0, 1, 1, 0, 0, 0)(Transponiert)
M: -1 -1 0 0 1 0 1 0 0 -1 0 0 0 0 1 0 -1 0 1 0 -1 0 0 0 0 1 0 0 1 -1 0 0 0 1 -1 0
Nein. Durch t4→t5→t2→t6→t6 verschwinden alle Marken!
t4→t5→t6→t1→t4
a)
for(int i = 0; i < nStages; i++){ boolean lastThread = (i == threads.length - 1); inQueue<Integer> = queues[i]; outQueue<Integer> = queues[i+1]; threads[i] = new StageThread(i, inQueue, outQueue, lastThread); threads[i].start(); }
b)
2) Integer value = inQueue.take();
3) outQueue.put(runStage(value));
4) if(!lastThread) outQueue.put(value);
return; break auch möglich!
a) Siehe Zeile 11-12: Prüfe-Handle-Wettlaufsituation. Beide bekommen die Mitteilung, dass das Lock frei ist. Eine Behebung des Problems wäre beispielsweise über ein synchronized(this) um das If möglich.
b) Wenn f==t ist, dann wird zweimal aufs gleiche Konto und somit aufs gleiche Lock zugegriffen wird. Dann bekommt man eine IllegalMonitorStateException.
c) in 59-60: Deadly Embrace: Thread A will von Konto X zu Konto Y buchen, Thread B von Y zu X. Beide lokcen in 59 das erste Konto und warten in 60 auf das zweite Konto, dass sie aber nie bekommen können, da der andere Thread es besitzt. Möglichkeiten zur Behebung: Globale Ordnung über die Nummer des Kontos, oder Synchronized auf ein Objekt.
d) in 71 kann das Geld abgefragt werden, danach wird die Bank unlocked. In withdraw kann Geld von einem Konto geändert werden, dass in der obigen Funktion bereits angeschaut und das Geld aufaddiert worden ist. Die Beträge sind dann unterschiedlich.
Gefixt über B.L.unlock() von 72 am Ende der Funktion.
a)
def construct: (Int => Boolean) => (Int => Int, Int => Int) => Int => Int =
i ⇒ (e, o) ⇒ n ⇒ if(i(n)) e(n) else o(n)
b) def f: Int ⇒ Stream[Int] = n ⇒ n #:: f(c(n))
c)
// toList vor foldLeft ist optional, Stream bietet auch diese Funktion def oddCount: (Int, Int) => Int = (n, k) => f(n).take(k).toList.foldLeft(0)( (a, b) => if(isEven(b)) a else a+1)
a)
def getFreeColor: List[Color] => Color = c => { def helper : (List[Color], Int) => Color = { case (Nil,n) => n case (cs,n) => if(!cs.contains(n)) n else helper(cs,n+1) } helper(c,0) }
oder eleganter:
def getFreeColor: List[Color] => Color = l => (for(i <- List.range(0, l.length + 1 ) if !l.contains(i))yield i).head
Alternativ mit dropWhile:
def getFreeColor: List[Color] => Color = ms => List.range(0,ms.length+1).dropWhile(ms.contains(_)).head
Rekursive Alternative:
def getFreeColor: List[Color] => Color = cs => { if (cs.contains(0)) { getFreeColor(cs.map(_-1)) + 1 } else { 0 } }
Oder mit foldLeft
def getFreeColor: List[Color] => Color = list => list.foldLeft(0)((a,b) =>if(list.contains(a))a+1 else a)
b)
def colorGraph: List[Node] => List[Coloring] => List[Coloring] = { nod => cols => nod match { case Nil => cols case n::ns=> colorGraph(ns)(nextFreeColor(cols)(n)::cols) } }