Threadsafe
Moderator: Moderatoren
- Manfred
- Foren-Administrator
- Beiträge: 21191
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Threadsafe
Dieser Begriff ist nun schon öfter gefallen. Aber was bedeutet Threadsafe eigentlich genau und woran kann man erkennen ob etwas Threadsafe ist, oder nicht?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2825
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Threadsafe
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.
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.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Manfred
- Foren-Administrator
- Beiträge: 21191
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Threadsafe
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?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2825
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Threadsafe
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
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
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Manfred
- Foren-Administrator
- Beiträge: 21191
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Threadsafe
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!?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2825
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Threadsafe
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:
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.
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:
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.weil man wiederholte Aufrufe nicht berücksichtigt, dann ist das nur unsauber, hat aber nichts mit Threadsafe zu tun!?
Code: Alles auswählen
STATIC nCounter := 0
FUNCTION CountUp
nCounter++
RETURN(nCounter)
FUNCTION CoundDown
nCounter--
RETURN(nCounter)
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Manfred
- Foren-Administrator
- Beiträge: 21191
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Threadsafe
OK,
dann liegt das Problem woanders. Danke für die Ausführung.
dann liegt das Problem woanders. Danke für die Ausführung.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Threadsafe
"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.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Threadsafe
hi,
ich sehe gerade das ich es so verwendewenn ich das richtig erinnere hatte ich am Anfang "LOCAL oThread4" ...
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)
gruss by OHR
Jimmy
Jimmy