Zitat:
Denn wenn Public, und es wird lockStringList aufgerufen, und mit dieser dann gearbeitet, ist das Teil nicht THreadsave.
Doch, sie ist dennoch sicher, da dann die CS sperrt und somit andere keinen Zugriff haben.
Vorteil bei der offenen deklaration, man kommt auch mal richtig an die StringListe ran, falls man sie z.B. mal sortieren oder sonstwas damit machen will.
Delphi-Quellcode:
sl := ThreadStringList.lockStringList;
try
// mache irgendwas
// z.B.: sl.Delete(AIdx);
finally
ThreadStringList.unlock;
end;
Ob man sowas nun außerhalb macht oder innerhalb der ThreadStringList, ist dabei vom Schutz her egal.
Bin da zwar zum Großteil mehr der Theoretiker, aber glaubs mir einfach ... mit den angemerkten Änderungen isses OK.
Und nein, ich hab den Code jetzt garnantiert nicht durchgesehn, aber ich seh diesbezüglich auch keine Schwachstellen ... solange man nicht an der CS vorbei auf die StringList zugreifen kann, was ja nicht der Fall ist.
Gut, man könnte jetzt zwar denken, daß String dankt seiner Referenzzählung jetzt noch ein Problem darstellen kann, da er nach dem Get ja nur eine Referenz auf den String in der internen StringList besitzt, aber die Referenzzähung bei Strings ist threadsicher ausgelegt (auch wenn man das knuffige "LOCK" in den entsprechenden Assemblercodes leicht übersieht) und wenn dann noch der Speichermanager auf Threadbetrieb eingestellt ist, dann gibt es diesbezüglich keine Probleme.
Der Einzige Schwachpunkt läge darin, wenn man dann absichtlich den Schutz umgeht, aber wer das macht, der muß dann auch mit den Konsequenzen leben.
Delphi-Quellcode:
sl := ThreadStringList.lockStringList;
try
// mache irgendwas
// z.B.: sl.Delete(AIdx);
finally
ThreadStringList.unlock;
end;
// mache was unsicheres mit der StringList
SL.Add('fdsafds');