Einzelnen Beitrag anzeigen

reaktor

Registriert seit: 1. Aug 2012
9 Beiträge
 
#9

AW: Thread sichere Datenabfrage

  Alt 30. Okt 2020, 10:13
Ist dein Programm reinzufällig 32 bit?

Wenn ja und der von dir angegebene Code einigermaßen der Realität entspricht und die Threads so laufen, wie ich es denke, hätte ich eine mögliche Erklärung.
zu finden unter:
https://hub.packtpub.com/common-prob...l-programming/

Dort werden ein paar (nicht gleich so eindeutige) Fallstricke bei geteilten Ressourcen erklärt.
Ein Beispiel geht um die Problematik mit 64 bit Datentypen (int64) wenn der Processor im 32 bit Modus arbeitet. Um die Variable auszulesen braucht der Prozessor zwei Schritte. Und zwischen diesen beide Schritten kann der Writer-Thread den noch nicht gelesenen Teil überschreiben. Je nachdem was der Writer-Thread nun manipuliert, könnte es FReadDataValueNum oder FDataReader.ValueCount sein. Dadurch kommt für idx ein nicht plausibler Wert raus und dann scheitert auch der Zugriff das Array oder die Liste. Das könnte auch das sporadische Auftreten erklären.
Selbst wenn das jetzt nicht die Ursache ist, fand ich den Beitrag irgendwie spannend. Das Buch kann ich auch empfehlen, falls man das hier überhaupt darf.

Zitat:
Mein größtes Problem ist grade tatsächlich auch das generelle Verständniss
Hab mich auch erst kürzlich damit beschäftigt. Wenn mir Sachen einfallen die mir geholfen haben, poste ich sie.


Zitat:
Prinzipiell sollte es auch bei mir irgendwo in der Nähe des Codes zum schreiben und lesen bereits etwas geben was die threadsicherheit garantiert. Denn es geht ja auch das Rückblättern schon
Kann auch reiner Zufall sein (?). Gerade das Fehler finden fand ich bei Threads ziemlich eklig. In solchen Fällen habe ich mir oft mit Debugstrings geholfen (OutputDebugString ist thread-sicher, das Auslesen des Int64-Wertes wie gesagt unter 32 bit aber nicht).


Auf jeden Fall musst du dich um die Synchronisation kümmern.
Such am besten erstmal ob das nicht schon irgendwo passiert. Soweit ich das verstanden habe, kannst du eine Critical section relativ weit "außen" setzen, also z.B. gleich bei der ersten Funktion, die dann weitere Funktionen aufruft (Ich finde leider die Quelle dazu nicht mehr. Bitte korrigiert mich, wenn das nicht stimmt). Gut möglich, dass dein ehemaliger Kollege die Synchronisation auf einer anderen Ebene eingebaut hat.
Der, durch CS geschützte Code, sollte allerdings wegen Deadlocks und Performance so kurz wie möglich bleiben. Und es müssen natürlich alle Threads auf die CS eingehen, nicht nur einer.

Ist keine Synchronisierung vorhanden, musst du diese (unbedingt!) einbauen. Aber an welchen Stellen und mit welchen Mitteln, kann ich leider von außen nicht beurteilen. Halt immer dort wo es vorkommen kann, dass zwei oder mehrere Threads auf eine geteilte Ressource zugreifen. Gut möglich, dass es an den Pointern oder den Dateien liegt. Evtl auch das Bit-Problem oder einfach nur ein ungeschützer Zugriff auf Variablen oder Klassen.

Hier noch ein kleiner Link zu CS:
http://www.delphicorner.f9.co.uk/articles/op4.htm

und hier noch einer zu simplen Datentypen und deren Threadsicherheit:
https://stackoverflow.com/questions/...es-thread-safe

Viel Erfolg!
  Mit Zitat antworten Zitat