Seite 1 von 1

Bloch’s Thread Safety Levels

Verfasst: 29. Jul 2010 12:51
von Pascha
Hallo,
mir ist noch nicht zu 100% die Grenze zwischen dem Conditionally und Compatible Level klar. Gibt es da irgendwelche "Signalwörter" auf die es zu achten ist.

Bzw. was heißt "eine Methode ist an sich Thread-Safe"? Heißt es, dass ich diese Methode von mehreren Threads gleichzeitig ausführen kann, ohne dass da Probleme entstehen? Und lediglich eine Kombination aus diesem Methodenaufruf und dem Aufruf einer anderen Methode zu Problemen führen wird?

Und liege ich mit meiner Annahme richtig, dass mit dem Hinzufügen einer neuen Methode zu einer Klasse, sich der Thread-Safety Level der Klasse niemals steigern kann, da die alten Methoden, die den ursprünglichen Level bestimmt haben, immer noch vorhanden sind?

Re: Bloch’s Thread Safety Levels

Verfasst: 30. Jul 2010 13:20
von Pascha
*aufeineantwortwart* :)

Re: Bloch’s Thread Safety Levels

Verfasst: 1. Aug 2010 12:19
von eichberg
Signalwort: Nein - eine genaue Analyse des Verhaltens der Methoden und Ihrerer Abhängigkeiten ist notwendig.
Bzw. was heißt "eine Methode ist an sich Thread-Safe"? Heißt es, dass ich diese Methode von mehreren Threads gleichzeitig ausführen kann, ohne dass da Probleme entstehen? Und lediglich eine Kombination aus diesem Methodenaufruf und dem Aufruf einer anderen Methode zu Problemen führen wird?
Genau. (Studieren Sie die Implementation der Klasse Vector für Beispiele solcher Methoden).

Ihre Vermutung ist richtig: durch zusätzliche Methoden (wenn der Rest 100% gleich bleibt) kann der "Thread Safety Level" nicht steigen.

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 17:01
von Jo(h)nny
wir haben eine frage zu aufgabe 2 in der sommersemesterklausur 2009...zu dem thread safety level der List<T>-Klasse.

es kann ja passieren, dass verschiedene threads verschiedene listen halten, weil beispielsweise ein thread b durch prepend(T e) ein element an die liste vorne dranfügen kann, ohne dass es thread a mitbekommt. es kann also passieren, dass unterschiedliche threads unterschiedliche listen halten...die teillisten sind zwar identisch, aber die listen können unterschiedlich lang sein.

ist das jetzt trotzdem konsistent und valide im sinne des thread-safety levels (also immutable), oder wird dadurch die thread-safety zerstört (also thread-hostile)? :shock: :shock:

danke euch schonmal für die antworten :roll: :roll:

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 17:16
von satabin
Hi,

Welche Listen können unterschiedlich lang sein? Ändert prepend das Objekt?
Was ist für dich Immutability und was ist thread-hostile?
Wenn du diese Fragen beantworten kannst, solltest du die Antwort haben :)

Lucas

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 17:43
von Jo(h)nny
nun ja wie es aussieht, können wir die Fragen leider nicht beantworten und sind auf deine Hilfe angewiesen:)

nein, Spaß bei Seite, also immutable ist für mich ein Objekt, das ich nicht verändern kann. In diesem Fall kann ich ja das Objekt nicht ändern, weil die setFunktionen nicht definiert sind.
Die Listen sind zwar unterschiedlich lang, innerhalb eines Threads sind die Listen aber gleich lang, d.h. die Threads können andere Threads nicht beeinflussen, ich denke das heißt für uns schon mal mindestens thread-safety.

Also ich würde mal sagen, dass in diesem Fall die Objekte immutable sind und durch das Hinzufügen der Iterator-Funktion ändert sich nichts. Ist das richtig so?

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 17:52
von satabin
Du konntest die Fragen beantworten, die Definitionen sind in den Folien ;)
Du konntest auch sagen, ob die Liste sich ändern kann, dann... Eine Lösung bringt wirklich etwas, nur wenn man daran überlegt hat, nicht unbedingt, wenn man die fertige Lösung bekommt ;)
Dein Satz verstehe ich aber nicht mit den Threads und unterschiedlichen Längen. Kannst du mir ein Beispiel geben, das illustriert was du meinst?

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 18:07
von Jo(h)nny
heisst das jetzt, dass wir die Frage richtig beantwortet haben? Es ist ja nicht so, dass wir nicht über die Frage nachgedacht haben:)

Also mit den Threads hab ich mir eigentlich folgendes gedacht: wenn ein Thread startet, erzeugt er eine neue Liste(oder bekommt eine). Wenn der Thread jetzt irgendwas in die Liste schreiben will, macht er "prepend" und bekommt den Kopf einer neuen Liste. Die anderen Threads halten aber immer noch den alten Kopf und deswegen beeinflusst das Einfügen eines neuen Elements die anderen Threads nicht.

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 18:29
von satabin
Aber kann man in der Liste schreiben? i.e. kann man das Objekt erweitern mit neuen Elementen?
Du hast es gesagt, du erzeugt ein neues Objekt mit prepend: so, kann man das Objekt ändern? Wenn nein, ist das Liste-Objekt Immutable, und es ist straightforward. Wenn ja, kannst du ein Szenario finden (und es hier geben), in dem wir einen inkonsistenten Zustand für das Liste-Objekt haben?
Inkonsistenz kann kommen, weil zwei Threads gleichzeitig auf ein Objekt zugreifen, und dieses Objekt mit nicht atomaren Aktionen ändern (z.b Test und dann Field ändern...).
In deinem Szenario, sehe ich keinen Inkonsistenten Zustand in dem Liste-Objekt, da das Objekt unverändert bleibt. Der Thread, der prepend aufruft kriegt eine neue Instanz mit dem neuen Element. Aber was ist mit der ursprünglichen Instanz (die eigentlich das Shared-Objekt ist...)?
Du sagst, dass es immutable ist und das es sich nicht ändert mit dem Iterator. Gut du hast erklärt, warum Liste immutable ist. OK, dann was sagen du Folien falls es Immutable ist? ich glaube, dass es hier kein Problem gibt. Wird diese Immutability Property geändert durch die getIterator Methode? Du hast es nicht begründet, warum es sich nicht ändert. Kann dieser Iterator die Liste ändern? Ich bin sicher, dass du die Antwort hast, ich will nur, dass du es erklärt.
Ich könnte dir sofort sagen: "die Antwort ist so und so", aber es bringt mehr für dich, wenn du selbst die Begründung schreibst...

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 18:43
von Jo(h)nny
also das mit dem inkonsistenten Zustand war eigentlich so gedacht, dass die Threads auf unterschiedlichen Listen arbeiten. Die Frage war also, ob man das als "inkonsistenter Zustand" bezeichnen kann.

Alles klar, in dieser Aufgabe war also alles immutable und nach dem Hinzufügen von Iterator ändert sich nicht.
Danke schön für die Antworten :)

Re: Bloch’s Thread Safety Levels

Verfasst: 2. Aug 2010 18:44
von satabin
Ja aber hier diesem Fall (Thread Safety des Liste-Objekts), die Inkonsistenz des Objekts ist zu betrachten. Wenn alle Threads alle Änderungen bekommen müssen, musst du ein anderes Model nehmen. In diesem Fall wird dein Liste-Objekt keinen inkonsistenten Zustand erriechen.