|
Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
Hallo Zusammen!
Ich glaube Jeremy North hat mal geschrieben: „Wenn ich für jede Frage: „Ist das Thread-Safe“, einen Dollar bekommen würde, bräuchte ich nicht mehr zu arbeiten“ (frei übersetzt)… Ich möchte hier mal diesen Diskussion-Thread :lol: starten um die häufigsten Frage und Antworten zu sammeln. Was bedeutet eigentlich Thread-Safe? Oder müsste die eigentliche Frage lautet: „Ist xy  reentrant?“ Also was darf ich in einen Thread machen und was nicht und wann brauche ich ein Syncronize? Wenn man(n) nach Thread safe googled oder auch DP’ed bekommt man schon unzählige Antworten. Jedoch beantworten 99 von 100 Suchergebnissen nicht den „eigentlichen“ Kern der Frage, oder? Was ist den Atomar? Wann brauche ich ein critical section? Wann brauche ich eine Semaphore? Oder reicht mir ein Spinlock? Sicherlich gibt es hierzu Tutorials. Zum Beispiel hier!Besonders bemerkenswert ist hieraus folgenden Satz: Zitat:
Das lassen wir einfach mal so stehen. Aber ist die VCL/FMX reentrant? Reden wir hierbei von den Komponenten oder über die Systemroutinen? Was gehört zu dieser VCL Aussage? Was ist mit einem lesenden Zugriff in einem Thread nach dem Motto:
Delphi-Quellcode:
Brauche ich für den Zugriff auf Edit10.Text ein Syncronize?
procedure TMyThread.Execute;
var S : String; begin while not(Terminated) do begin S := Edit10.Text; Foo(S); End; end; Was kann passieren? OK, nochmal zurück zum Grund der Frage. Warum möchte man überhaupt einen Thread erzeugen? a.) Eine Verarbeitung soll parallel laufen oder im Hintergrund b.) Die Software soll schneller werden. c.) ?? Erst mal zu b. Zitat:
Aber was will ich den beschleunigen? Bei „normalen“ Programmen (was ist schon normal) wartet die Software zu 99,9% auf die Eingabe des Benutzers. Aber dann… Wenn der Benutzer eine Aktion ausführt soll es doch möglichst schnell gehen. Es wurde dann immer gesagt: „Mach doch die komplizierte Berechnung in einem Thread!“ Was ist den eine komplizierte Berechnung und woher kommen die Daten? Wir reden ja nicht davon Pi auf 1000 Stellen zu berechnen, sondern eher von 3*7+StrtoInt(Edit10.Text) + 19% MwSt. Summe(SQL-Table)… Aber genau da kommen wir zu „unserem“ Punkt. Können 2 Thread’s StrtoInt aufrufen? Was ist mit einer SQL-Abfrage? Dateioperationen? Drucker Zugriff? Ich könnte mir vorstellen, dass eine TTable die auf ein Formular geklickt wurde „schlecht ist um in einem Thread benutzt zu werden, aber was ist wenn ich diese im Thread lokal erzeuge? Gibt es System Routinen die nicht gleichzeitig von mehreren Thread aus aufgerufen werden dürfen? Was ist mit den Indy-Routinen? Ich nutze gerne einen Thread für http oder SOAP Requests. Funktioniert prima… Aber das gehört eher zu (a) Wie lange muss meine Routine eigentlich dauern, damit es sich lohnt diese in einen Thread aus zu lagern? Das erzeugen des Thread’s mit kompletten overhead kostet ja auch Zeit. Also für die 10 Fälle wo ich einen Thread brauche diesen schon beim Programmstart erzeugen? Kann ich das erzeugen der Threads in einen Thread auslagern? :-) Nutzt mir hier ein ThreadPool?Benötige ich meinen Thread immer wieder, füttere ich „Ihn“ also nur mit neuen Daten und setze einen Event? Oder erzeuge ich den Thread jedes mal neu? Wie ist denn meine Aufgabenstellung? Fragen über Fragen und dann noch die Unsicherheit ob das alles so Safe ist… oder ob ich mir Deadlocks erzeuge…Kommen wir mal zurück zu Punkt (a) Schön ist es wenn ich eine Verarbeitung in einen Thread auslagern kann, dieser Thread dann - wenn er fertig ist - eine Procedure aufruft, die dann das Ergebnis verarbeiten kann. (Idealfall) Was ist aber wenn ich auf das Ergebnis warten muss? Beispiel: Ich habe eine http Request und will das den erhaltenen content dann verarbeiten. Solange ich nicht das Ergebnis in meinem Workflow brauche, sondern die Inhalte nur gespeichert werden sollen. Prima, aber was wenn der User damit etwas machen soll? Ich starte also den Thread für den Request… Mache „schnell“ noch was anderes im Vordergrund task und dann? Muss ich auf das Ergebnis warten, oder ist es schon da? Das hängt natürlich von der Internet und CPU Geschwindigkeit ab. Diese also dann vorher testen und dann entscheiden ob Thread oder nicht? Ich denke es gibt hier noch genügend Fragen die noch zu beleuchten sind. Auch weil die Thread Implementierung von Delphi zu Delphi Version immer „besser“ geworden ist. Wie sind Eure Erfahrungen? Wie häufig nutzt Ihr Threads und wo für? Soll man eine Library nehmen oder von Fall zu Fall den Thread neu programmieren? Wie sieht es auf anderen Plattformen aus? Android/iOS/Mac… Lasst und mal sammeln… Grüsse Mavarik PS.: Die Intention dieses Threads 8-) ist eine Sammlung für alle interessierten zu zentralisieren. Die Aufgestellten Fragen sind nicht meine (naja vielleicht ein/zwei davon schon) :stupid: |
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Save?“
|
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Save?“
OT:
Und du hast nur die Spitze des Eisbergs gesehen, Google mal nach "thread safe". Da kippste um! Sherlock -dem man so früh am Morgen den Rechtschreib-Flame verzeihen möge |
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Save?“
Zitat:
Aber wenigstens konsequent durchgesetzt... Zitat:
|
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
Ich glaube, 'ist das threadsafe' kann man sich anhand der Definition im Wiki selbst beantworten.
Die Frage lautet, wann setzt man Threads sinnvoll ein? Mir fallen drei Szenarien ein:
|
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Save?“
Zitat:
Gruß K-H |
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
Zitat:
Zitat:
Zitat:
|
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
Zitat:
Eine parallele Verarbeitung ist doch was schönes. Egal wie schnell eine einzige CPU noch werden kann. Vielleicht existiert ja auch Software, die nicht nur auf simple Usereingaben wartet. Zitat:
Wie im Wikipedia Artikel auch beschrieben, zieht das zwangsläufig ebenso nach sich, dass ein Thread oder nenn es auch "Vorgang" in seiner Arbeit für eine bestimmten Moment nicht unterbrochen werden darf (durch einen Interrupt) Die Threadsicherheit geht je nach verwendeter CPU schon bei einem normalen Integer verloren. 4 Byte. Zwei Threads arbeiten mit einer Integervariablen. Der eine schreibt gerade die erste Hälfte von den 4 Bytes, der andere Thread liest aber gerade in dem Moment die Integervariable. Du siehst, die Daten sind nicht die, die Du erwartest und schon gar nicht logisch richtig. Ein Boolean ist wohl wirklich atomar Threadsicher. Atomar bedeutet einfach, dass die Technick herum um die Software irgendwann nur noch die Threadsicherheit übernehmen kann. In dem Fall die CPU. Critical Sections selbst müssen atomar sein. In dem Fall vom Betriebssystem zur Verfügung gestellt. Zitat:
Schon das Arbeiten mit einer Liste muss abgesichert werden. If list.Count > 0 .. dann mache irgendwas, kann schon zu Programmabstürzen führen, wenn gerade in dem Moment ein anderer Thread was aus der Liste löschen würde, und bei der Abfrage: list.count noch ein Element drin ist, und dann beim Zugriff auf das Element es auf einmal gar nicht mehr da wäre. Zitat:
Zitat:
Das Anhalten eines Threads mit einer Critical Section führt in hochperformanten Anwendungen zu Performance Verlusten. Ein Spinlock lässt den zu wartenden Thread einfach ein paar Millisekunden im "Kreise" drehen, und wenn dann die Freigabe immer noch noch nicht erteilt ist, erst dann geht er in "Ruhezustand".. Für all Deine beschriebenen Anwendungen, die nur auf "Usereingaben" warten ist das alles nicht relevant. *smile* Für nähere Infos siehe auch Microsofts "InitializeCriticalSectionAndSpinCount" function. Allerdings sind Spinlocks bei Zugriff auf Daten von mehr als 2 Threads großer Mist und werden in der Praxis meiner Erfahrung nach etwas "hakelig". Manche Threads kommen dann gar nicht gleichranging zum Zug. Da ist die Betriebssysteminterne Verwaltung mit Critical Sections tausend Mal besser. Da gehts geordnet der Reihe nach, die Threads werden vom Betriebssystem in geordneter Reihenfogle aus dem Ruhezustand geholt. Wenn man all seine Programme versteht, ist alles gar nicht so schwer .. Ein sauberer modularer Programmierstil ist unerlässlich mit sauberen Schnittstellen nach außen... |
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
@stoxx
Wenn ein Integer nach deiner Darstellung nicht sicher ist, dann kann auch ein Boolean unsicher sein (hängt davon ab wie ein Boolean intern gespeichert/verarbeitet wird). Bei 32bit werden allerdings - soweit mir bekannt - immer genau 4 Bytes (=32bit) bearbeitet, und deswegen ist ein 8/16/24/32bit-Wert auf einem 32bit-Betriebssystem threadsafe, denn die CPU lockt dafür den Speicherplatz (32bit) im Arbeitsspeicher. Darum ist es ja auch ein 32bit-Betriebssystem, das eine 32bit CPU benötigt. Darum sind 64bit-Programme teilweise langsamer, weil eben bei jedem Zugriff immer 64bit bewegt (doppelte Menge).
Ehrlich gesagt würde ich aber selbst einen Zugriff auf einen Integer mit einem Lock absichern, bzw. eigentlich tausche ich fast immer komplexere Datenelemente mit einem Thread aus, wo alles enthalten ist um die Aufgabe zu erledigen. Mit nur einem Integer-Wert ist das eher selten möglich :) |
AW: Die Frage aller Fragen (Sammlung): „Ist das Thread-Safe?“
Zitat:
Auch egal, wie er gespeichert, verarbeitet wird, nämlich immer dann, wenn der Wert geprüft wird, und dann vielleicht geändert. (ist das gleiche Problem, wie unten mit dem increment vom Integer beschrieben) Zitat:
das hängt von der CPU ab. Ein auf dem eigenem Rechner programmiertes und getestes Programm muss noch lange nicht stabil überall funktionieren. So pauschal kann man das nicht sagen. Es hängt nicht vom Betriebssystem ab, sondern von der CPU (und vom Compiler) .. Hier mal beispielhaft die Aussagen von Intel https://software.intel.com/en-us/forums/topic/308940ich hab auch irgendwo mal eine komplette umfangreiche Liste gefunden, ich werde mal suchen ... Nicht atomar zu sein heißt ja auch, 2 Threads wollen einen Wert incrementieren. Beide lesen den Wert 5, und schreiben (leider gleichzeitig) 6 hinein. Wenn das beide gleichzeitig machen, steht am Ende 6 drin, obwohl 2 Threads zweimal hochgezählt haben und 7 drinstehen müsste. Daher auch die existierende Windows Funktion InterlockedIncrement .... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz