Code: Alles auswählen
type
tdaten = record; // (shortstrings, byte, ints, doubles >> also nur zahlen und 2 shortstring)
tarr_dat = array of tdaten;
var
globA : array of tarr_dat; // mein globales 2 dim. dynamisches array, wird im hauptprogramm 1 x beim Create resized auf z.b. SetLength(globA , 40 , 0);
procedure TEvoThread.Execute;
var
tmp : tarr_dat;
_pos : Byte;
begin
_pos := getpos(tid); // pos für diesen thread, bereich 0..39, vereinfacht dargestellt eigentlich läuft hier ein Syncronize
while(w1) do begin
tmp := nil; // (erstes) vorher SetLength(tmp,0)
while(w2) do begin
[.......] // tmp[] wird resized und neu befüllt
end;
if(Length(globA[_pos]) <> Length(tmp)) then globA[_pos] := nil; // oder immer nil setzen?
globA[_pos] := tmp;
tmp := nil; // (zweites) eigentlich unnötig, nur für Frage 4
end;
end;1. Ich habe vorher SetLength(0) verwendet, allerdings finden sich gegenteilge Aussagen darüber ob SetLength(0) auch wirklich den Speicher komplett freigibt? Bzw. bleiben da wohl paar Bytes übrig, in meinem Fall taktet das alle 100 ms, da sollen keine Bytes übrig bleiben?
2. array := nil soll schneller sein als SetLength(0), mir kommts genau andersrum vor? Was ist richtig nil, SetLength(), Finalize()?
3. Wie man sehen kann wird globA[_pos] := nil; gesetzt, danach globA[_pos] := tmp; die Referenz kopiert, ohne vorab SetLength auf globA[_pos] anzuwenden. Ich wollte eigentlich nur mal testen ob das geht und es geht, gibts dazu Bedenken? Muss ich vorab SetLength() verwenden? Wäre es sinnvoller immer globA[_pos] := nil; zu setzen vor dem kopieren?
4. tmp := nil; (zweites) >> Wäre ja eigentlich unnötig da tmp beim verlassen der routine eh freigegeben wird. Ich habe jedoch gelesen (daher die Frage), dass dieses nil dafür sorgt das globA[_pos] dann ebenfalls nil sein soll??? Ist es aber nicht und genau das will ich auch so, in meinem globalen Array sollen ja die Daten vorhanden bleiben. Meiner Meinung nach wird die Referenz kopiert und tmp "genilt", globA[_pos] enthält dann die einzige Referenz, wenn ich dann später globA[_pos] := nil setze dürfte alles freigegeben sein oder? Was wäre wenn ich SetLength(tmp,0) an dieser Stelle mache? Liege ich richtig das ich dann Copy() nutzen müsste, da sonst ebenfalls Length(globA[_pos]) = 0 ist??
5. if A and B are dynamic arrays, never write A := B; Quelle "http://delphiblog.twodesk.com/dynamic-arrays-how-they-work-and-how-to-use-them"
In meinem Fall kopiere ich die Referenz eines eindimensionales dyn. Array in die 2. Dimension eines zweidimensionalen Arrays. Why not? Wäre globA[_pos] := Copy(tmp); besser / schneller / langsamer?
6. Das globale Array wird durch 10 verschiedene Threads befüllt, jeder Thread befüllt immer den selben Speicherplatz. Die Anzahl also Length(tmp) variiert. Nur die Threads dürfen in globA schreiben, nil setzen oder Änderungen vornehmen. Ich muss aber im Hauptprogramm nach jedem Thread(s)durchlauf das Array lesen. Ist der schreibende (thread) / lesende (main) Zugriff problematisch?
Fettes Danke !!!!!!
! Danke!
!! Wo du es sagst, es steht noch oben in den uses, aber auskommentiert und ich weiß jetzt auch wieder warum. Da ich beim Beenden selbst alles leere, lösche und freigebe war da nie etwas was aus meinem Code stammte. Trotzdem sprang heaptrc immer beim Beenden an, weil es in irgendwelchem anderen Code Leaks gefunden hatte, es war irgendwas von Lazarus irgendwelche Komponenten die ich nicht alle ändern mag und ich musste das Lazarus neu kompilieren mit -glh um überhaupt zu sehen das es gar nicht in meinem Code war 
. Aber funktioniert das auch während ein Thread loopt? Geht das zur Laufzeit? Ich kann doch nur beim Beenden schauen ob alles ok ist, ist es aber weil meine Routine alles freigibt?
??
... Es scheint doch so zu sein wie ich befürchtet habe, SetLength(a,0) setzt auf 0, der Speicher wird jedoch anscheinend nicht sofort (wie bei a:= nil) freigegeben. Macht man das 300 x kein Problem, aber in "heavily used environment" kann das ohne ein nil irgendwann AccessViolations erzeugen. Diese Aussage beschreibt genau meine AccessViolation, nicht reproduzierbar, ich habe an keiner anderen verdächtigen Stelle einen wirklichen Fehler gefunden + passender Logeintrag.
Verein
Links
Suche