Hallo.
Ein mMn sehr guter Beitrag zum Thema Synchronisation von Bernd Ua:
Video:
https://www.youtube.com/watch?v=WOc89TF8l-8
Material:
http://probucon.de/wp-content/upload...ronisation.pdf

Zitat:

Gibt es eine Lese bzw. eine Schreibfunktion in der von Haus aus eine Lock integriert ist? und erst wenn das Fertig ist, kann ein anderer thread wieder darauf zugreifen?

Neben Critical Sections, TMonitor und vielen anderen gibt es noch eine threadsichere Warteschlange: TThreadedQueue.
Beispiel dazu hier:
http://chee-yang.blogspot.com/2015/1...eadsynchronize

Evtl ist auch TMultiReadExclusiveWriteSynchronizer für dich der richtige Weg.
Auszug aus dem o.g. PDF:

TMultiReadExclusiveWriteSynchronizer :
• Verwaltet mehrere lesende Zugriffe und
blockierenden Schreibzugriff
• BeginRead/EndRead zum Lesen
• BeginWrite/EndWrite zum Schreiben
• Zum Beispiel verwendet von der VCL via
IReadWriteSync in Forms (GlobalNamespace)

In dem Buch "Delphi Cookbook" gibt es, glaube ich, ein Beispiel für ein Oszilloskop was auf Multi-Threading basiert. Die Problemstellung klang jetzt auf Anhieb irgendwie ähnlich.

Tut mir leid, dass ich keine konkretere Hilfe anbieten kann.

hihi das video hab ich grade auf. Danke dir @Reaktor

Mein größtes Problem ist grade tatsächlich auch das generelle Verständniss, was aber vermutlich einfach daran liegt das der Code in dem ich arbeite schon die eine oder andere zeile hat... und davon auch einfach viel nicht von mir ist, sondern von jemandem den ich deswegen auch nicht mehr fragen kann...

Zitat:

Evtl ist auch TMultiReadExclusiveWriteSynchronizer für dich der richtige Weg.

Das hört sich interressant an. Das muss ich mir mal ansehen.

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, wäre das nicht sicher dürfte auch dieser Teil nicht richtig funzen, ich bin leider bisher nicht dahinter gekommen, wie das genau funktioniert: Da keine critical section, Monitor synchronize oder sonstiges aufgerufen wird, ist das für mich grade nicht ganz plausibel... Das einzige was mir auffällt ist das die Lese und Schreib Prozesse über Pointer verbogen werden o.O . Vielleicht liegt es aber auch daran das die Datei jeweils zwischen gebuffered wird. So richtig Sinn bekomme ich in die Sache nur leider heute iwie nicht rein...

Zitat:

In dem Buch "Delphi Cookbook" gibt es, glaube ich, ein Beispiel für ein Oszilloskop was auf Multi-Threading basiert. Die Problemstellung klang jetzt auf Anhieb irgendwie ähnlich.

Prinzipiell ist es mehr oder minder genau das was ich gerade Bastel. Ein Oszi in dem Zurückgespult werden kann und das gleichzeitig das Signal auswertet. Was mich gerade iritiert ist das es läuft - Denn himitsu hat recht, das lesen und schreiben sollte sich eigentlich beißen... naja. Ich werde mir das Buch mal holen, verkehrt ist das sicherlich nicht.

Statt CriticalSection gibt es seit 'ner Weile auch TMonitor.
(Achtung, nicht das TMonitor aus TScreens sondern aus System ... ja, ich weiß der Name ist doof/irrsinnig/verwirrend, aber wenn jemand strunzdoof von C# klaut kopiert, dann kommt sowas bei raus)

Die TMonitor können an ALLE TObjekt angehängt werden.
Besonders geil, weil man so keine Extra-Variable braucht und es sogar ohne Umbauten an Fremdkomponenten nutzen kann (z.B. an einer TStringList).

markieren

Delphi-Quellcode:

TMonitor.Enter(MyList); // siehe auch TryEnter/Wait/Pulse und der Timeout im Parameter
try

finally
  TMonitor.Exit(MyList);
end;

Statt TMonitor.Enter geht auch MonitorEnter

und könnte man sich auch selbst via ClassHelper als Methoden an TObject/TMyList/... hängen.

markieren

Delphi-Quellcode:

MyList.Enter; // oder z.B. Lock und Unlock
try

finally
  MyList.Exit;
end;

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!

Zitat:

Ist dein Programm reinzufällig 32 bit?

Ja, ...

Das werde ich mir Montag mal in Ruhe ansehen. Das könnte durchaus so sein. Das würde mich allerdings dezent verunsichern, denn ich nehme Codeelemente die mehr oder minder genauso auch an anderen Stellen für ähnliche Zwecke verwendet werden ... Ich Tippe aber drauf das ich wirklich noch irgendeinen Mechanismus zum Sperren einfach immernoch nicht gefunden habe, der in irgendeiner Hintertür eingebaut ist. Die Reader und Writer Elemente sind einfach extrem verschachtelt.

Die Basics und auch wie ich eine CS verbaue habe ich drauf. Ich denke das ich auch mit dem TMonitor gut zurecht kommen würde (bisher nie verwendet). Mit amphoren und so weiter habe ich gottseidank noch keine Berührungspunkte, das wird aber vermutlich in ein oder zwei Jahren dann unumgänglich . Mal sehen wie sich das Projekt weiterentwickelt.

Über das Wochenende werde ich einfach mal einen Test mit vielen Daten starten. Wenn es mir bis Montag um die ohren fliegt weiß ich wenigstens sicher das es ein Problem gibt. Sonst muss ich weiter suchen bis ich die Lösung gefunden habe.

Ich danke euch für den großartigen Input! Ich mach mich mal auf die Suche und melde mich sobald ich was herausfinde!