Auf Thema antworten

Sorry, hast Du natürlich recht, das Wort ist mir glatt entfallen, peinlich!



Nein, das meine ich nicht. Sicher impliziert immutability thread-safety und wenn ich jetzt rein funktional programmiere (und Monaden außen vor lasse) arbeite ich auch thread-safe ;-)


Wenn wir die Formulierung jetzt auf die Goldwaage legen wollen, dann klar, das Wort syncronized impliziert keine thread-safety. Die korrekte Verwendung davon in einer Klasse tut dies für Exemplare der Klasse schon. Dabei muss natürlich korrekt und vollständig, im Kontext des gleichen Synchronisationsobjekts eine Sperrung erfolgen.


Natürlich kann ich auch auf andere Art eine Anwendung thread-safe bekommen, aber Exemplare einer Klasse, in welcher jede Methode syncronized markiert ist sind thread-safe. Es wäre allerdings nicht für jede Klasse sinnvoll jede Methode auf diese Art zu synchronisieren, da es a) vielleicht völlig unnötig ist und b) man vielleicht auch verschiedene Synchronisationsmonitore verwenden sollte um das Laufzeitverhalten für verschiedene Anwendungsfälle zu verbessern.

Aber nochmal, die Synchronisation erfolgt um thread-safety zu erreichen und tut dies auch. Natürlich kann ich jetzt sagen, dass ich die Ressource public deklarieren und von außen einen konkurrierenden Zugriff ermöglichen könnte, so dann wäre dieser nicht thread-safe oder ich lasse das synchronized für mindestens eine Methode aus, die auf die Resource zugreift oder natürlich kann ich einen Synchronisationmonitor an ein Objekt binden und in einem statischen Kontext verwenden. Sehen wir also von konstruierter Fehlbenutzung ab (wird können ja wohl GMV annehmen), dann sehe ich nicht was synchronized für einen anderen Zweck hat als thread-safety zu erreichen (natürlich nur in korrekter Benutzung).



Oben