Ich nutze die OTL nicht, aber ich bin mir sehr sicher, dass in der Dokumentation oder in Demos niemals derartig auf ungeschützte Objekte zugegriffen wird. (das würde mich jedenfalls sehr wundern, wenn dort derart grob fahrlässige Fehler drin wären)
Klar kann man so darauf zugreifen, aber niemals "ungeschützt" in einem Thread, es sei denn dieser
eine Thread ist der
Einzige, welcher darauf zugreift.
Der Haupt-/MainThrad ist ja auch ein Thread und so lange etwas
ausschließlich darin läuft, kann es z.B. auch problemlos auf die
VCL (
GUI) zugreifen.
Zitat:
Delphi-Quellcode:
Status := Liste.Strings[0];
Liste.Delete(0);
Wenn ein anderer Thread zwichen diesen Beiden Befehlen die Liste verändert (Add/Append/Delete), dann rate mal was hier wohl schief laufen kann.
Noch schlimmer ist es, dass der andere Thread auch "mitten" in einem der beiden Befehle einschlagen kann ... dann wird nicht nur dieser eine Index betroffen, sondern es kann auch das gesamte Programm zerstören, indem es beim Speichermanagement was schrottet.
* eine CriticalSection um das Auslesen+Delete (alternativ gehen auch andere Synchronisiermethoden, wie z.B.
TMonitor.Enter oder siehe
SyncObjs)
das Benutzten des "Status" im Anschluss muß nicht da drin sein, da es die "globale" Liste nicht mehr betrifft.
PS: statt Delete kann man auch Remove benuten, dann ist es nur noch ein Befehl.
Aber auch dieser ist nicht "atomar" und
muß demach abgesichert werden.
* Rate mal, warum ich die
TThreadList erwähnt hab, denn Jene hat bereits eine Sicherung eingebaut, welche Thradübergreifende Konflikte abfängt.
Beispiel für atomare Befehle:
Inc(i);
hat Probleme, wenn mehrere Threads gleichzeitig den selben Speicher verändern wollen.
Darum gibt es
InterlockedIncrement /
InterlockedIncrement, bzw. inzwischen auch
AtomicIncrement, als platformübergreifende Variante. (nicht nur Windows, sondern auch Android, iOS usw.)