Threadsafe

[Manfred]

Dieser Begriff ist nun schon öfter gefallen. Aber was bedeutet Threadsafe eigentlich genau und woran kann man erkennen ob etwas Threadsafe ist, oder nicht?

[georg]

Hallo, Manfred -


lass es mich an einem Beispiel erklären, und ich hoffe, es ist korrekt so.

Du hast in einem Thread eine DBF-Datei geöffnet und stehst auf Satz 25. Jetzt startest Du einen zweiten Thread, der mit derselben DBF-Datei arbeitet. In beiden Threads wird der gleiche Alias verwendet. Wenn Du im zweiten Thread jetzt auf Satz 26 gehst, und sich der Satzzeiger im ersten Thread ebenfalls auf Satz 26 bewegt, ist die Datenbanksteuerung nicht threadsafe.

(Unter normalen Umständen sollte dies auch nicht passieren, da Xbase++ in dieser Beziehung threadsafe ist.)

Threadsafe bedeutet, dass Veränderungen in einem Thread sich nicht auf entsprechende Entitäten in einem anderen Thread auswirken.

Anderes Beispiel: Du öffnest aus zwei Threads eine TCP-IP Verbindung zum gleichen Host, gleichen Port. Dann werden die gesendeten/empfangenen Daten nicht "vermischt", wenn die Zusatzbibliothek threadsafe ist.

[Manfred]

Also Threadsafe heißt nicht, dass alles was im Thread abläuft (z.B.) dafür sorgt, dass nach Beenden des Threads auch aufgeräumt wird? Was weiß ich, Objekte destroyed usw? das es z.B. durch immer fortwährende Aufrufe desselben Threads nicht den Speicher vollschreibt?

[georg]

Hallo, Manfred -


unter threadsafe wird verstanden, dass Threads sich nicht gegenseitig beeinflussen (es sei denn, dass der Programmierer das will). Aufräumarbeiten gehören damit leider immer noch zu den Arbeiten, die bei uns als Programmierer hängenbleiben.

Zur Definition habe ich noch das gefunden: http://en.wikipedia.org/wiki/Thread_safety

[Manfred]

Ist immer noch nicht richtig rübergekommen, was ich meine. Aber ich habe verstanden. Das Aufräumarbeiten auf uns zurückfallen ist klar, aber Threadsafe heißt ja auch das der Entwickler seine Hausaufgaben gemacht hat. Wenn es denn auch so gewollt war. Ich wollte nur wissen, ob schlechte Aufräumarbeiten unter nicht Threadsafe fallen, oder ob die in diese Kalkulation nicht einbezogen werden. Also wenn man sich den Speicher zuknallt, weil man wiederholte Aufrufe nicht berücksichtigt, dann ist das nur unsauber, hat aber nichts mit Threadsafe zu tun!?

[georg]

Hallo, Manfred -


Dein erster Beitrag deutete in eine andere Richtung.

Grundsätzlich wird kaum jemand eine "Thread-Bibliothek" anbieten, sondern eine Bibliothek mit Lösungen. Wir als Programmierer verwenden dann Funktionen (oder Klassen, etc.) innerhalb unserer Threads.

In diesem Zusammenhang stellt sich die Frage, ob diese Funktionen, Klassen etc. threadsafe sind oder nicht, d.h. ob sie parallel in Threads ausgeführt werden können, ohne sich gegenseitig zu stören.

Ob sie "den Speicher vollknallen" hat wenig mit Threads zu tun, denn wenn wir die Funktionen im "normalen" Umfeld einsetzen, würden sie sich ja genauso verhalten.

Aber genau der Punkt, den Du hier anführst, hängt damit zusammen:

weil man wiederholte Aufrufe nicht berücksichtigt, dann ist das nur unsauber, hat aber nichts mit Threadsafe zu tun!?

M.E. ist die Verwendung von STATICs etwas, das nicht threadsafe ist, zumindest nicht ohne zusätzlichen Programmieraufwand. Es gab da ein Beispiel von Alaska mit zwei Routinen, die eine zählt aufwärts, die andere abwärts. Verwendet wird dort eine STATIC, die den Zähler enthält.

Code: Alles auswählen

STATIC nCounter := 0

FUNCTION CountUp
  nCounter++
RETURN(nCounter)

FUNCTION CoundDown
  nCounter--
RETURN(nCounter)

In dem Moment, wo ich zwei Threads laufen habe, die CountUp und CountDown verwenden, beeinflussen sich die Threads gegenseitig, obwohl das (normalerweise) nicht gewollt ist. Dieser Code ist nicht threadsafe. Um ihn threadsafe zu machen, muss der Programmierer sicherstellen, dass für jeden Thread eine eigene Variable nCounter existiert.

[Manfred]

OK,

dann liegt das Problem woanders. Danke für die Ausführung.

[Tom]

"Threadsafe" in unserem Kontext bedeutet vor allem, dass das Starten von Modulen in eigenen Threads gegeneinander abgesichert sein muss. Verwendet man beispielsweise PUBLICs, um irgendwelche Einstellungen oder Eigenschaften zu verwalten, beeinflusst dies auch das Verhalten von Modulen in Threads, da PUBLICs tatsächlich applikationsglobal sind. Was also bei einem einmaligen Start eines Moduls noch funktionieren würde, könnte beim nächsten Parallelstart knallen. Ein anderes Beispiel sind Fremdmodule - beispielsweise Reportgeneratoren -, die via DllCall() genutzt werden, was zur Folge haben kann, dass sich diese Fremdmodule in bestimmten Zuständen befinden können, die vorübergehend einen weiteren Zugriff nicht erlauben (oder wenn Module beispielsweise Fensterhandles benötigen, um mit der App zu kommunizieren). Hier ist es nötig, den Ladevorgang in jedem/für jedes Modul zu wiederholen, also nicht auf globale Objekte zuzugreifen. Und so weiter.

[AUGE_OHR]

hi,

ich sehe gerade das ich es so verwende

Code: Alles auswählen

STATIC oThread4 := NIL                          // reuse it

   oThread4:setStartTime(SECONDS()+5+5+5)
   oThread4:start("NEWF2",@lExit)

   bSaveError := ErrorBlock()
   ErrorBlock( {|e| Break(e)} )
   BEGIN SEQUENCE
        // hier Aktion
        // wenn er "zu lange" braucht kommt die Aktion von oThread4
   RECOVER USING oError
      ErrorBlock( bSaveError )
   END SEQUENCE
   ErrorBlock( bSaveError )

   // Thread abbrechen
   oThread4:setStartTime(NIL)
   oThread4:setInterval(NIL)

wenn ich das richtig erinnere hatte ich am Anfang "LOCAL oThread4" ...