Frage zu Nebenläufigkeit

[Foermchen82]

Folgendes Szenario:

Eine Applikation beinhalten einen Service, der singelton ist.

Zwei Threads greifen gleichzeitig auf die gleiche Methode zu. In dem Service gibt es keine globalen Variablen außer DAOs.

Jeder Zugriff auf die Methode liefert Eingangsparameter, für die Berechnungen angestellt werden.

Kann es hierbei zu Kollisionen der Threads kommen, oder Arbeitet jede Methode für sich?

Danke im voraus

 

[Gast2]

Solange da nichts weiter synchonsiert werden muss können die Threads gleichzeitig die Methode im Singleton aufrufen. Wenn die Methode wirklich nur lokale Variablen nutzt sollte da kein weiteres Problem mit bestehen.

 

[tfa]

Was ist mit den DAOs? Sind das Membervariablen der Service-Klasse? Wenn die dann nicht threadsicher sind, knallt es früher oder später.

 

[maki]

Kann es hierbei zu Kollisionen der Threads kommen, oder Arbeitet jede Methode für sich?

ganz klar: Vielleicht

Programme werden nicht automatisch oder gar zufällig Threadsicher, entweder sie sind bereits so geschrieben, oder du sitzt auf einer Zeitbombe.
Solche fehler sind übrigens schwer nachzustellen.

 

[Foermchen82]

Was ist mit den DAOs? Sind das Membervariablen der Service-Klasse? Wenn die dann nicht threadsicher sind, knallt es früher oder später.

Ja das die DAOs thread sicher sein müssen ist klar.

Aber die Methoden an sich arbeiten dann schon separat, oder?

 

[Andi_CH]

Ja das die DAOs thread sicher sein müssen ist klar.

Aber die Methoden an sich arbeiten dann schon separat, oder?

Was heisst "separat"???

Es ist ein und derselbe Code der durchlaufen wird.
Natürlich benutzt jede "Instanz" des Codes das Stacksegment des aufrufenden Kontextes
Statische Variablen sind aber nur einmal vorhanden
Objekte die über Referenzen angesprochen werden sind möglicherweise auch nur einmal vorhanden
( -> singleton -> ist in dem Fall ja klar)


Vielleicht muss ich es so sagen:
Methoden arbeiten gar nicht - es sind die Threads die arbeiten und die arbeiten den Code ein und derselben Methode ab - aber es sind zwei Threads

Hm - ob das klarer ist???:L

Wolltest du das wissen? Wenn nein, habe ich dich falsch verstanden.

 

[Tente]

Wenn du die gleiche Methode zur gleichen zeit aus dem gleichen Objekt aufrufst ist das eine Kollision... NIIIIE GUT. außer bei gettern, da kannste drauf scheißen. liefern ja nur n wert. aber wenn du methode aufrufst die berechnet, muss die threadsicher sein! Allein der Zugriff über singleton auf die Instanz kann zur Kollision führen. Lies mal ne Runde über das Schlüsselwort "volatile"...

 

[SlaterB]

> aber wenn du methode aufrufst die berechnet, muss die threadsicher sein!
'ne Methode die berechnet' gegenüber getter ist ja recht ungenau,
solange eine Methode keine statischen/Klassenatttribute benutzt kann sie 10 Min. lang mit lokalen Variablen rechnen, da stören sich mehrere Aufrufe nicht gegenseitig

Collections.sort() ist z.B. eine anschauliche Methode die jede Menge rechnet udn nicht synchronisiert werden muss

 

[Foermchen82]

Machen wir mal ein Beispiel:

die Methode soll in einer for-schleife Zahlen mit sich selbst multiplizieren. Das ganze 10 mal. und die eigentliche Zahl kommt als Aufrufparameter in die Methode. Alles mit lokalen Variablen.

Jetzt greifen 2 Threads gleichzeitig auf die Methode des Singeltons zu.

Was nun? Ist das ein Problem, oder laufen die Berechnungen korrekt ab?

 

[tfa]

Dann hast du ja keine Daten, auf die konkurierend zugegriffen wird.
Wenn alle Variablen lokal oder immutable sind, ist eine Methode threadsicher.

 

[Foermchen82]

richtig. die einzige Konkurrenz ist, dass es die gleiche Methode ist. Also ist sowas unkritisch, richtig? Ich muss halt nur sicherstellen, dass ich keine globalen variablen verwende, und wenn doch muss der zugriff threadsave sein.

 

[hdi]

Jeder Thread hat seinen eigenen Stack mit lokalen Variablen, und wie tfa schon sagte ist dein Beispiel also threadsafe.

Aber Vorsicht: Falls es sich bei den lokalen Variablen um welche von einem komplexen Datentyp handelt, und du per Punkt-Notation derefernzierst, kann es wieder krachen, insofern zwei Threads die selbe Referenz nutzen (was zB der Fall wäre wenn die selbe Variable von beiden Threads als Parameter in die Methode übergeben wird). Denn durch die Dereferenzierung schaffst du dir das eigentliche Objekt aus dem Heap ran, und im Gegensatz zu Stacks teilen sich alle Threads einen einzigen Heap! Dann musst du auf diese Variable wieder synchronisieren, obwohl sie lokal ist!

 

[SlaterB]

> Also ist sowas unkritisch, richtig? Ich muss halt nur sicherstellen, dass ich keine globalen variablen verwende,

wenn die Methode intern sauber ist, ist eine unvermeidbare Gefahr dann noch die Parameter von außen,
je nachdem wie intensiv man mit denen interagieren muss kann es fatal enden, wenn eben auf diesen externen Daten zwei Threads gleichzeitig arbeiten,

aber das kann überall im Programm passieren, nicht nur in dieser Methode,
nur als Hinweis dass eine Methode an sich nicht immer restlos ohne Fehlermöglichkeit besteht,

bestenfalls werden die externen Daten kopiert wie es Collections.sort() macht (wobei eher aus anderen Gründen),
aber auch der kurze Kopiervorgang kann unsicher sein und nicht immer ist das möglich/praktikabel

 

[Foermchen82]

Ok, ich weiß definitiv, dass die Eingabeparameter nicht in mehreren Threads verwendet werden. Aber der Hinweis ist gut. danke.

Also sehe ich zu, dass um die Methode herum alles sauber ist und thread-safe und die Methode selbst nur lokale Parameter verwendet.

Danke an alle

 

[hdi]

Ok, ich weiß definitiv, dass die Eingabeparameter nicht in mehreren Threads verwendet werden

Wahrscheinlich hast du mich schon richtig verstanden, aber ich will sicher gehen: Es kann jetzt nicht nur an den Eingabeparametern liegen, sondern generell daran dass du mit den selben Objekten arbeitest:

void doStuff(int i){
    Database.getCurrentObject().edit();
}

Thread 1:
doStuff(5);

Thread 2:
doStuff(20);

...wenn die edit-Methode des current object nicht synchronisiert ist, kracht's! Schon klar oder.. Hat alles nix mit lokalen/globalen oder Parameter-Variablen zu tun..

 

[Foermchen82]

Wahrscheinlich hast du mich schon richtig verstanden, aber ich will sicher gehen: Es kann jetzt nicht nur an den Eingabeparametern liegen, sondern generell daran dass du mit den selben Objekten arbeitest:

void doStuff(int i){
    Database.getCurrentObject().edit();
}

...wenn die edit-Methode des current object nicht synchronisiert ist, kracht's! Schon klar oder.. Hat alles nix mit lokalen/globalen oder Parameter-Variablen zu tun..

Ja das ist mir klar. Ich wollte jetzt nicht alle Möglichkeiten eines globalen Zugriffs aufführen *g*