Lokale Variable Threadsicher?

[saihttam]

Moin zusammen,
bei uns ist eine heiße Diskussion über Threadsicherheit entbrannt... hoffentlich gibt es hier eine klare Antwort.

Folgendes:
1..n Threads benutzen ein einmal erzeugtes Objekt.
Die Threads rufen eine Funktion namens Cmd parallel auf.

Code:

function TMyObject.Cmd(tx: String; var rx: String): Boolean;
var
  myClient: TMyClient;
begin
  //myClient erzeugen
  //myClient benutzen 
  //FreeAndNil...
end;

Jetzt gibt es zwei Theorien.

1. Die 'myClient' wird bei parallelen Aufrufen an den gleichen Pointer erzeugt. Und damit ist diese Konstrukt NICHT thread-sicher!

2. 'myClient' wird an verschiedenen Pointern erzeugt und solange man keine globale Variablen benuzt, ist es thread-sicher.
2a. Wenn den so ist warum funktioniert dann Rekursion.

Danke+Gruß
Matthias

[Uwe Raabe]

Die lokalen Variablen und die Parameter einer Methode werden auf dem Stack angelegt oder es wird ein Register der CPU benutzt. Das ist in jedem Fall threadsicher. Bei Pointern, dynamischen Arrays und Klasseninstanzen (sind ja auch Pointer) muss man aber wiederum aufpassen. Die Inhalte liegen nämlich nicht auf dem Stack.

In dem konkreten Beispiel wird aber die Klasseninstanz innerhalb der Methode erzeugt und freigegeben. Das ist wiederum sicher.

Rekursion hat damit erstmal gar nichts zu tun. Auch hier muss man eine konkrete Implementation sehen, um Threadsicherheit beurteilen zu können. Es gelten da die gleichen Bedingungen.

[sahimba]

Zitat von Uwe Raabe:

In dem konkreten Beispiel wird aber die Klasseninstanz innerhalb der Methode erzeugt und freigegeben. Das ist wiederum sicher.

Das lässt sich so nicht sagen, da wir nicht wissen, was die Instanz der erzeugten Klasse intern "tut". Möglicherweise greift diese auf globale Strukturen zu ohne sich um eine Synchronisierung zu kümmern.

[saihttam]

@Sir Rufo
Ich habe mir abgewöhnt Compilerwarungen zu ignorieren, das rächt sich irgendwann...

Es geht darum, dass ein weiterer Service via TCP angesprochen wird. Am Empfängerservice ist zu sehen, dass die Anfragen nahezu zur gleichen Zeit (<=1ms) ankommen und den gleichen Port benutzen.
Deswegen war ich auf die lokalen Variablen gestoßen.

Das Ganze konnte ich zum Testen mit einer TCriticalSection lösen, also muss das Problem ja innerhalb dieser Funtkion liegen. Sind Firmensourcen daher kann ich den Code leider nicht einstellen.

[jaenicke]

Zitat von saihttam:

Es geht darum, dass ein weiterer Service via TCP angesprochen wird. Am Empfängerservice ist zu sehen, dass die Anfragen nahezu zur gleichen Zeit (<=1ms) ankommen und den gleichen Port benutzen.

Und wie wird diese Kommunikation gemacht? Wirklich rein mit lokalen Variablen?

Oder steckt da vielleicht eine TCP-Verbindungskomponente global unter private oder so... (denn ich vermute ja nicht, dass die Verbindung ständig neu aufgebaut wird)

Eine Möglichkeit dies ohne Synchronisation zu lösen:
Statt var einfach threadvar, dann ist die globale Variable threadspezifisch.

[saihttam]

In diesem Fall wird die Verbindung aufgebaut und direkt wieder geschlossen.

Ich benutze die Indy's TIdTCPClient Klasse. Mein Source ist sehr übersichtlich. Ich glaube deswegen (momentan) nicht, dass es an meinem Source liegt. Variablen benutze ich dort eigentlich nur lesend (Zielname, -port, timeout-Konstanten), der Rest sind die Parameter (rx, tx) der Funktion.

Stimmt 'threadvar' hatte ich schon verdrängt. Werde ich mal versuchen...

Ich mache nu' Feierabend,
euch ein schönes WE!
Gruß Matthias

[Uwe Raabe]

Zitat von sahimba:

Zitat von Uwe Raabe:

In dem konkreten Beispiel wird aber die Klasseninstanz innerhalb der Methode erzeugt und freigegeben. Das ist wiederum sicher.

Das lässt sich so nicht sagen, da wir nicht wissen, was die Instanz der erzeugten Klasse intern "tut". Möglicherweise greift diese auf globale Strukturen zu ohne sich um eine Synchronisierung zu kümmern.

Das hatte ich ja mit den Ausführungen in dem Abschnitt davor gemeint.

In dem Fall liegt das Problem aber nicht in der Methode selbst oder an der dort erzeugten Klasseninstanz (d.h. jeder Methodenaufruf verwendet seine eigene Klasseninstanz - auch bei Multithreading), sondern an der Implementation der Klasse. Darüber können wir aber allenfalls spekulieren.

[jaenicke]

Zitat von saihttam:

2. 'myClient' wird an verschiedenen Pointern erzeugt und solange man keine globale Variablen benuzt, ist es thread-sicher.

Wobei du zu den globalen Variablen auch die Felder des Objekts zählen musst, zu dem deine Funktion Cmd gehört, also was dort unter private, public usw. steht.

Zitat von saihttam:

2a. Wenn den so ist warum funktioniert dann Rekursion.

Weil du dort die Parameter für den einzelnen Aufruf als Parameter übergibst. Du benutzt dort ja nicht die selbe lokale Variable über mehrere Rekursionsschritte hinweg.

Beispiel:

Delphi-Quellcode:

function Test(const a: Integer): Integer;
begin
  if a > 1 then
    Result := Test(a - 1)
  else
    Result := 1;
end;

Wenn du dort z.B. 3 übergibst, wird innerhalb deines Aufrufs Test(3) noch einmal Test(2) und Test(1) aufgerufen. Ob du darin dann jeweils noch einmal lokale Variablen benutzt oder nicht, ist egal. Denn die gelten jeweils nur innerhalb des aktuellen Aufrufs. Das sich in der Rekursion ändernde Element ist a, also der Parameter. Und der wird auch nur dem jeweiligen Aufruf mitgegeben.

Wir könnten hier sicherlich auch erklären wie das intern genauer funktioniert, aber ich glaube das führt zu weit und verwirrt eher. (Auch wenn es sehr interessant sein kann. )

[Der schöne Günther]

Falls Ihr euch regelmäßig zum Philosophieren über den Begriff Threadsicherheit trefft - Ich fand den kleinen Artikel ganz nett: Eric Lippert - What is this thing you call thread-safe?

[Sir Rufo]

Zitat von saihttam:

1. Die 'myClient' wird bei parallelen Aufrufen an den gleichen Pointer erzeugt. Und damit ist diese Konstrukt NICHT thread-sicher!

Das ist generell schon mal absolut falsch - und wäre auch absolut tödlich

Delphi-Quellcode:

function MyFactory : TObject;
var
  LObj : TObject;
begin
  LObj := TObject.Create;
  Result := LObj;
end;

Wenn das so wäre, dann würde man sich ja bei jedem Aufruf die vorherige damit erzeugte Instanz vernageln.
Kann also definitv nicht zutreffen.