Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Wissensfragen-Fragen
Hallo,
war mir bei folgenden Wissensfragen nicht ganz sicher.
Die Fragen sind aus den letzten 5 Klausuren zusammengestellt.
Falls jemand ein paar Antworten weiss oder sagen kann, was nicht stimmt:
- Ist es richtig, dass bei Verwendung thread-sicherer Klassen Wettlaufsituationen entstehen können?
Antwort: Ja - Müssen Instanzen der Klasse ThreadLocal direkt in den beteiligten Threadklassen deklariert und initialisiert werden?
Antwort: Ja, zumindest habe ich es noch nie anders gesehen. - Wenn mehrere Threads gleichzeitig eine synchronized-Methode aufrufen, werden die Aufrufe dann garantiert in First-Come-First-Served-Reihenfolge abgearbeitet?
Antwort: Nein, glaube das gilt nur für nicht-statische synchronized-Methoden. - Betritt ein Thread einen synchronized(lockObject)-Block, werden für ihn Zustandsänderungen eines anderen Aktivitätsfaden sichtbar, die dieser nach einem synchronized(lockObject)-Block gemacht hat.
Antwort: Nein, dies ist nur garantiert, wenn diese Änderungen in dem synchronized(lockObject)-Block gemacht wurden. - Kategorie moderner Grafikkarten? SISD, SIMD, MISD, MDXI?
Antwort: SIMD - Voraussetzungen für Verklemmung (notwendig und/oder hinreichend)? Entzug, Iterative Programmabfolge, Zirkulare Abhängigkeit, Gegenseitiger Ausschluss
Antwort: Iterative Programmabfolge, Zirkulare Abhängigkeit, Gegenseitiger Ausschluss - Die cobegin-Struktur dient dazu, gleichartige Aktivitäten auf unterschiedl. lokalen Daten zu starten.
Antwort: Nein, da diese Aktivitäten nicht unbedingt gleichartig sein müssen. - Ein java-Thread kann mehrere synchronized-Blöcke, die mit derselben Marke geschützt sind, zur gleichen Zeit betreten.
Antwort: Nein, da ein Thread bzw. das zugehörige Arbeitspaket immer nur von einem Prozessor ausgeführt wird. Zur selben Zeit kann ein Thread sich nicht an verschiedenen Stellen im Programm befinden. - Eine Wettlaufsituation kann eintreten, wenn eine Aktivität Werte verändert, die eine andere Aktivität ebenfalls liest oder verändert.
Antwort: Ja - Ein Live-Lock kann in Java dadurch verhindert werden, dass alle gemeinsam genutzten Variablen als volatile deklariert werden.
Antwort: Ja - Bei Verwendung eines CompletionService wird sichergestellt, dass erst nachdem alle Tasks abgeschlossen sind, weitergearbeitet wird.
Antwort: Nein, dies ist optional
Nein, die kannst du prinzipiell überall deklarieren, das ist ein Objekt, wie jedes andere auch. Das, was du jeweils zurückbekommst, hängt vom aufrufenden Thread ab und nicht davon, wo es deklariert wurde.
Hmm, wieso sollte es hier einen Unterschied machen, ob static oder nicht? Im Allgemeinen ist da doch keine besondere Reihenfolge definiert, oder?
Hmm, hier ist die Frage, wie man das jetzt genau interpretiert. Ein Thread führt natürlich nicht gleichzeitig Code an verschiedenen Stellen aus, was er aber kann, ist verschachtelte synchronized-Blöcke, die mit dem gleichen Monitor geschützt sind, betreten. Hier wäre der Thread ja gleichzeitig in zwei entsprechenden synchronized-Blöcken: [m]synchronized (this) { synchronized (this) { doMagic(); }}[/m] (oder vielleicht realistischer: andere synchronized-Methoden aufrufen).
- Ja
- Nein, kann auch in Klassen sein die von den Threads verwendet werden. ThreadLocal in der API
- Nein, es gibt generell keine Garantie dafür das First-Come-First-Served eingehalten wird.
- Nein, er sieht nur was der andere Thread vor und in seinem synchronized(lockObject)-Block gemacht hat.
- SIMD. (Ist MDXI nur zur Verwirrung da oder hat das auch eine Bedeutung in der Flynnschen Klassifikation?)
- Entzug wird genutzt um eine Verklemmung aufzuheben, die anderen sind notwendig oder hinreichend für eine Verklemmung
- Nein, unterschiedliche Aktivitäten erlaubt.
- Ja, synchronized sind ReentrantLocks. Wenn der Thread die Marken schon hat kann er einfach eine andere Methode mit der selben Marke betreten. Lock wird erst freigegeben, wenn der äußerste Aufruf verlassen wird.
- Ja
- Nein, siehe Folie 05-38 ff
- Nein
Ich bin gestern mal alle Altlkausuren durchgegangen und habe notiert, was ich angekreuzt hätte. Hier mal zum Vergleichen (bzw. Verbessern, falls jemandem ein Fehler auffällt):
19. Februar 2013
a) falsch
b) richtig
c) falsch
d) falsch
e) richtig
f) Speedup = 6, Effizient = 6/8 = 3/4
g) falsch
31. Juli 2012
a) falsch
b) falsch (nur die, die er vorher gemacht hat)
falsch (nur die, die diesen Block betreten wollen)
falsch
c) unendlich
21. Februar 2012
a) falsch
b) 21s+5*7s = 56s
c) parent: Kind
work: Beide(?)
d) Thread t = new thread(new Worker()); t.start();
f) falsch
09. August 2011
a) richtig
b) SIMD
c) gegenseitiger Ausschluss, iterative Programmabfolge, zirkulare Abhängigkeit
d) Speedup: ¼, Effizienz: 1/12
e) richtig (Frage auf Scala bezogen)
22. Februar 2011
a) falsch
b) richtig
c) ungünstige Fragestellung. run wird mittels start() aufgerufen
d) falsch
e) richtig
f) falsch
g) falsch (die nicht minimalen Wege werden erst von reduce herausgefiltert)
h) falsch
03. August 2010
a) richtig
b) als Blockstruktur, Methodendeklaration
c) falsch
d) Laufzeit: O(log n), Effizienz: O(1/(log n))
e) richtig
f) falsch
g) richtig
h) (auf Scala bezogen) falsch
i) falsch (sie muss eine Funktion als Parameter oder Ergebnis haben?)
23. Februar 2010
a) falsch
b) richtig
c) falsch
falsch
d) Laufzeit einer Stufe: x → Gesamtlaufzeit seq.: 30x, par.:10x
Speedup: 3, Effizienz: 3/5
e) falsch. Beide Threads müssen jeweils die Resource bereits belegen, die der andere belegen will
f) richtig
04. August 2009
a) richtig
falsch
richtig
b) richtig
c) falsch
d) falsch
e) Speedup: 8, Efizienz: 2
f) richtig
17. Februar 2009
a) nein
nein
ja
b) nein
c) Speedup: 2, Effizienz: 2/3
d) Sichtbarkeitssynchronisation
e) nein
f) nein
29. Juli 2008
a) falsch
b) bei primitiven Datentypen: nein
c) MIMD
d) Sichtbarkeitssynchronisation, gegenseitiger Ausschluss
e) ja
nein
nein
f) falsch
richtig
Probeklausur
a) richtig
b) richtig
2010-08-03
e) Hätte ich richtig angekreuzt. Bessere Lastverteilung als bei statisch
2012-07-31
b) alle falsch
2009-08-04
f) hätte ich falsch gesagt ist aber mehr geraten als gewusst. Grund es ist nicht angegeben, das zwei Threads die selben Resourcen belegen wollen. Aber das ist wieder ne Frage wie man den Satz interpretiert.
Da gebe ich dir im Nachhinein recht.
Stimmt natürlich auch. Die Frage muss ich im Kopf verdreht haben.
Ich hätte gesagt, es ist eine notwendige, aber nicht hinreichende Bedingung. Das ist ja nichts anderes als eine iterative Anforderung.
MDXI ist soweit ich weiss nur zur Verwirrung da, in den Übungen hatten wir SISD, SIMD, MISD und MIMD (gemäß Flynn), sowie SPMD.
21.2.2012 c) work: würde ich sicher Beide ankreuzen, da work unbedingt ausgeführt wird.
31.7.2012 c) Gehört die Startbelegung nicht zum Petri-Netz?- sonst würde ich sagen unendlich
22.2.2011 c) Hier würde ich eigentlich run sagen, da durch Aufruf von start der Thread noch nicht direkt zur nebenläufigen Ausführung gebracht wird, sondern erst, wenn ein Prozessor zugeteilt ist die run-Methode ausgeführt wird. (Die Frage ist etwas zweideutig, da man dies durch start veranlasst…)
Würde ich auch gerne wissen. Wenn eine andere Startbelegung auch ein anderes Petri Netz ist, dann sind es klar unendlich, ansonsten gibt es doch nur eins oder?
Ein Netz ist unabhängig von seiner Startbelegung. (Die richtige Antwort würde sich aber auch nicht ändern, wenn eine Startbelegung gegeben wäre.)
Sprich die richtige Antwort ist 1?
edit: Hier ergänzend mein Ansatz für die Wissensfragen der letzten Klausur:
30. Juli 2013
a) richtig
b) richtig
c) falsch
d) falsch
e) falsch → datenparalleles Verfahren
f) 2+4+5+6+1+(5*6) = 48s
g) richtig
h) falsch
. (hier habe ich gefailed)
Das musst du entscheiden 
Überleg dir wie die Matrix entsteht und ob das eine ein-eindeutige Abbildung ist.
Zur ersten Frage: versuch doch mal, soviele Netze wie möglich zu zeichnen 
Dann zum 30.7.2013:
Da hab ich bei der f) 42s, weil: 2+4+5+6+1+(4*6) = 42, man muss ja nur noch (#Pakete-1) (=4) mit der längsten Stufendauer multiplizieren, oder seh ich das falsch?^^
und bei der h) hab ich falsch. Da hatte ich letztens (aus irgendwelchen Gründen?!) auch „richtig“ gewählt, aber habe es gerade eben ausprobiert. Sollte eigentlich nicht funktionieren, sofern ich keinen Denkfehler habe.
Im Skript (06-30) steht jedoch: „Wenn die Größen der Arbeitspakete erheblich variieren oder nicht vorhersagbar sind, sollte man die Ablaufplanung manuell erledigen, damit man gute Laufzeiten erreicht.“
Hätte also falsch angekreuzt.
Wenn die Folien das sagen …
Mir ist zwar nicht klar, wie man das manuell sinnvoll planen soll, wenn man die Laufzeiten nicht kennt aber was solls.
Da krieg ich genau eins hin (crazy ascii art)^^
t2
s1 [] --->|--->[] s2
<---|<---
t1Imho #Pakete * Größte-Stufendauer + Summe der Stufen. So wurds jedenfalls auch in der Übung gemacht.
Da hast du recht. Es kann dann nur mit f((5)(6)) aufgerufen werden
Mit Eigenschleifen kannst du das zum Beispiel beliebig variieren → ∞
Zu 29. Juli 2008
1)b) Kann in einem parallel ausgeführten Java-Programm der Ausdruck n != n zu wahr ausgewertet werden, wenn n ein primitiver Datentyp (z.B. int ) ist?
Ist dies nicht möglich, z.B. wenn ein Thread A zuerst das n liest, dann ändert ein Thread B n und Thread a liest das geänderte n. Die Frage ist ob der Compiler hier in jedem Fall soweit optimieren muss, dass es nicht möglich ist, dass das n 2x gelesen wird.
1)e)
Man kann die Laufzeit eines parallelen Programms im Allgemeinen verbessern, . . .
• wenn man kritische Abschnitte in 2 oder mehrere kritische Abschnitte zerschneidet.
Ist dies wirklich falsch? Wenn ich einen kritischen Abschnitt in 2 zerteile und beide unterschiedliche locks haben, kann Thread B den 1. kritischen Abschnitt abarbeiten während Thread A bereits den 2. kritischen Abschnitt bearbeitet.