Mojen ihr Lieben, Ihr seid so cool!
wird damit das Array im Speichern woanders hin verschoben.
Ohhhh, jetzt hat was Klick gemacht

. Es wird von dem einzelnen Thread zwar "nur" die (seine) 2 Dimension resized, beim Vergrössern wird aber
das gesamte Array im Speicher verschoben, dass muss man natürlich erstmal wissen, weiß ich ja dank Euch jetzt

! Ach jetzt versteh ich das erst, ich hatte nen Denkfehler / Wissenslücke. Ich habe zwar jedem Thread seinem eigenen einzigen Speicherplatz im globalen Array verschafft - in der Hoffnung das sich dadurch Schreib / Lesezugriffe nicht stören.
Aber wenn z.B. Thread 5 seinen Platz resized und der wird grösser wird zwar augenscheinlich ja nur globA[4 (tid-1)][] resized, dazu wird aber das gesamte globA im Speicher an einem anderen Platz neu erstellt. So hat zwar jeder Thread seinen eigenen Speicherbereich aber der liegt dann auf einmal nicht mehr da wo er gerade noch war ??? Und genau das kann passieren während ein anderer Thread noch in den Daten rumwurstelt.
Da genau dieses Vergrössern nur sporadisch (manchmal nach 2 Stunden manchmal 3 Tage gar nicht) passiert, könnte es evtl. die (oder eine der) Ursache(n) sein! Verdammte Axt diese tückischen kleinen Käfer, weiß jetzt auch nicht ob es DER Fehler ist, aber es ist nicht stable. Sorry an alle die versucht haben mir das zu sagen, irgendwie hab ich es vorher falsch / unvollständig verstanden. Mal eine Nacht drüber schlafen neeeeech

.
Und wenn man das kapiert hat, versteht man auch warum in diesem Fall eine CriticalSection "helfen" könnte. Hier schreibt zwar keiner der Threads
direkt in den Speicherbereich des anderen, aber jeder kann
alle verschieben. Allerdings würde ich mir an dieser Stelle damit selbst ins Knie schiessen, mit einer CriticalSection geht dann in meinem Fall nichts mehr parallel.
Hmmm, wie und wohin kopiere ich denn nun am sinnvollsten die Daten wenn diese:
a) Gesammelt dem Main-Thread nach Beenden der Sub-Threads zur Verfügung stehen sollen.
b) Dem Sub-Thread aber beim nächsten Start und während seiner Laufzeit zur Verfügung stehen sollen und der / die SubThread(s) evtl. die Grösse ändern können muss? Während andere SubThreads aber auch gerade mit den Daten (aber nur mit den eigenen) arbeiten.
Kleine Klugscheißerei am Rande.
Wenn man was lernen will sind Klugscheißer immer willkommen, nur dumme Menschen haben damit ein Problem wenn jemand mehr weiß

! Und Du sprichst damit die Stellen an, die ich eigentlich im Verdacht hatte.
Erklär mal bitte wo Du und welche Probleme Du da siehst, mein Client läuft in MQL4 auf dem Metatrader 4 (der meine Software / Server) mit Daten versorgt und der Client arbeitet mit Unicode. Der Client erstellt Memory Mapped Files und kopiert alle paar Millisekunden in diese Daten, da er mit Unicode arbeitet, verwende ich im Server(Lazarus) OpenFileMappingW:
Code: Alles auswählen
type
TSymbolsArray = Array[0..255] of TSymbolsStruct;
PSymbolsArray = ^TSymbolsArray;
var
PSymbol : PSymbolsArray = nil;
procedure GetSymbolData(); // verkürzte Ablauf Darstellung ohne Prüfungen usw..., aktualisiert Daten im MainThread bevor die SubThreads starten
begin
if(PSymbol = nil) then begin
MMF_HANDLE_SYM := OpenFileMappingW(FILE_MAP_READ , False , PWideChar(WideString(MMF_NAME_SYM)));
PSymbol := MapViewOfFile(MMF_HANDLE_SYM , FILE_MAP_READ , 0 , 0 , 0);
end;
if(Assigned(PSymbol)) then begin
Symbol := PSymbol^;
end else..............
end;
Ich hab jetzt mal im Codeteil den ungefähren Ablauf dargestellt, der orginale Quellcode wäre zu umfangreich.
OpenFileMappingW und PSymbol := MapViewOfFile wird quasi nur einmal am Anfang gemacht
Die Schreib / Lese Zugriffe von Client und Server hab ich hier per Mutex / WaitForSingleObject gesichert, Dir macht aber Unicode / Ansi Bedenken oder?
PS: Und woher weißt Du das mit Unicode, vermutlich aus einer anderen Frage weil hier steht davon nichts oder?
DANKE

!!!