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.
Aufgabe 5.5
In der Angabe steht, dass man die Methode [m]lock[/m] benutzen soll um eine Gabel zu nehmen.
Darf man auch die davon abgeleitete Methode [m]tryLock[/m] verwenden?
Jep.
Macht aber nur bei der d) Sinn und geht natuerlich auch alles ohne 
Hmm eigentlich habe ich es bei der b benutzt xD
Habe ich die Aufgabenstellung falsch verstanden?
Je nachdem wie streng dein Tutor ist, könnte er das durchgehen lassen.
Nicht allerdings, wenn er folgendes genau nimmt:
Ich vermute einfach mal, dass dies bei dir nicht erfüllt ist 
Nö das mache ich garantiert nicht xD
Meine b sieht so aus, dass versucht wird beide gabeln zu bekommen und wenn das nicht geht wird eine eventuell schon belegte Gabel wieder freigegeben.
Wenn ich die Aufgabenstellung genau nehme ist dabei ja praktisch kein unterschied zur d, abgesehen davon, dass das ganze bei der d über ne extra Klasse gemacht wird?
Der Waiter hat die übersicht über alle Gabeln. Das kann man ausnützen
Oder du baust eine tryLock Variante…
Oder …
In der eat-Methode ist ja eine Endlosschleife. Soll diese irgendwann mittels Interrupt unterbrochen werden oder ist es gewollt, dass das Programm so lange läuft, bis der Benutzer is beendet? Falls zweiteres der Fall ist, müsste man sich auch nicht um ein korrektes Beenden der Threads kümmern?
Das ist der Sinn der Aufgabe. Wenn dein Programm korrekt läuft, dann läuft es ewig und es gibt keine Probleme. Kommt es jedoch zu Verklemmungen, dann geht es irgendwann nicht mehr weiter. Allerdings sollte sich die Endlosschleife nicht in deiner eat-Methode befinden, sondern die bereits implementierte run-Methode enthält ja schon diese Endlosschleife
Ohja, ich meinte natürlich die run-Methode und nicht eat.
Also ist es tatsächlich nicht nötig, in den Methoden in Dinner, die Threads zu joinen bzw. seinem ExecutorService shutdown() zu befehlen?
Hallo,
- Wieviele Gabeln sollen wir bei einem, bzw. 2 Philosophen zur Verfügung stellen?
- Wie sollen wir die Gabeln im allgemeinen abspeichern (Array außerhalb Methode; genügt Array in Methode?- funktioniert dann der Zugriff?)?
Danke
Es sind immer genausoviele Gabeln wie Philosophen vorhanden.
Das ursprüngliche Beispiel sind ja 5 Philosophen, die jeweils zwischen sich eine Gabel liegen haben (also insgesamt 5 Gabeln).
Und bei 2 Philosophen sitzen sich dann einfach 2 Philosophen gegenüber, mit jeweils 2 Gabeln an jeder Seite. 
In welche Datenstruktur du die Gabeln legst, spielt für das spätere Vorgehen eigentlich kaum eine Rolle.
Wenn du dir die Basis-Philosophen-Klasse, von der deine später selbst implementierten Philosophen erben sollen, ansiehst - genauer gesagt den Konstruktor - siehst du ja, dass jeder Philosoph über seine Gabeln (also welche ihm zustehen) selbst Bescheid weiß.
danke
Hallo,
wie soll das genau mit dem waiter bei der d) funktionieren?
In den Folien steht dazu nichts.
Pure Absicht 
Habs aber trotzdem mal ausführlich erklärt:
Ich verstehe noch nicht ganz den Unterschied zwischen der b) und der c). Für mich ist hier der einzige Unterschied, dass zuerst die rechte Gabel aufgenommen wird (also die mit der höheren Nummerierung), anstatt der linken. Und die Gabeln habe ich doch sowieso in einem Fork Array, also sind die doch per se durchnummeriert…?
Bei der b) musst du dafür sorgen, dass du die Locks gleichzeitig nimmst.
Bei der c) brauchst du das nicht, weil du dich an die Ordnung hältst.
Und ja die Forks sind durchnummeriert, aber was machst du am Rand? Der Tisch ist schließlich rund
Das ganze ist wie folgt gemeint:
Jeder Philosoph nimmt zuerst seine linke gabel, bis auf dem letzten, der will zuerst die rechte nehmen. Das führt dazu das es zu keine deathlock kommen kann, wenn man es richtig umsetzt.
Danke, jetzt hat’s gefunkt!