Das wird schon.
Man darf nicht zwischen verschiedenen Threads (auch die
VCL ist ein Thread) untereinander auf Daten zugreifen. Deshalb müssen die Threads sich gegenseitig abstimmen und den eigenen Ablauf ggf. anhalten. Für die
VCL funktioniert das mit Synchronize.
Das ist, denke ich, der wichtigste Punkt. Das Problem ist u.a. vereinfacht folgendes:
Thread 1 liest aus einem Speicherbereich Daten aus (z.B. ein Array das in einem Objekt steckt), während Thread 2 gerade in genau diesem Array hinten Daten drin ändert und dort reinschreibt.
Am Ende hat Thread 1 halb alte und halb neue Daten gelesen, die in sich halt nicht zusammenpassen, und hat damit dann natürlich Rotz gelesen.
Wenn gerade kein anderer Thread in die Daten schreibt, dürfen aber natürlich beliebig viele Threads gleichzeitig lesen, denn die stören sich untereinander ja nicht.
Für diese Zugriffe gibt es (grundsätzlich, das hat erstmal nichts speziell mit Delphi zu tun) einige Methoden damit sich die Programmteile nicht in die Quere kommen. Das sind zum einen Locks, Mutexe, Semaphore und Monitore.
Für das obige Szenario kann z.B. ein Reader/Writer-Lock verwendet werden. Jeder Thread der gerade Lesen will, holt sich einen Reader-Lock, liest die Daten, und gibt den Reader-Lock wieder frei.
Reader-Locks können beliebig oft gehalten werden.
Ein Thread der Schreiben will, versucht sich einen Writer-Lock zu holen. Das geht nicht, weil es noch Reader-Locks gibt die gehalten werden. Der Thread der das probiert blockiert nun an dieser Stelle bis er den Writer-Lock erhalten kann. Das hat insbesondere zur Folge, das weitere Threads keinen neuen Reader-Lock mehr holen können und hier auch blockieren, bis das wieder geht.
Wenn alle Threads die gerade lesen ihre Reader-Locks zurück gegeben haben, dann gibt das Betriebssytem den Writer-Lock frei und der schreibende Thread darf weiterlaufen. Der bekommt also den Writer-Lock, jetzt ist sichergestellt das gerade keiner mehr liest, und darf seine Daten schreiben. Danach gibt er den Writer-Lock wieder frei. Das erlaubt im Umkehrschluss wieder allen anderen Threads die lesen wollen, ihren gewünschten Reader-Lock jetzt endlich bekommen zu können, und diese können auch weiterlaufen.
Wenn Du Dich mit Thread-Synchronisation auseinandersetzen willst, solltest Du vielleicht ein paar Artikel zu den Konzepten, insbesondere
Mutex, Lock und Sempahor (beinhaltet meist schon Monitor) lesen (Wikipedia ist schon ganz okay-ish), und dann von dort aus weiter arbeiten.
Eine noch ganz wichtige Sache in Windows (bzw. nahezu jeder anderen UI-Technologie) ist, das nur genau ein einziger Thread auserkoren ist, UI-Elemente (Forms, Controls etc.) zu aktualisieren. Damit müssen dann andere Threads eben die Daten mittels mindestens einer der oben genannten Synchronisationsmethoden wohin schreiben, wo der UI-Thread dann lesen darf und am besten auch mitbekommt, das er diese Daten jetzt irgendwie anzeigen muss.
Das Synchronize in dem oben genannten Beispiel schreibt den Code (Update das Label mit diesem neuen Text) sozusagen als Daten auf den UI-Thread (im Prinzip schiebt er einen Zeiger auf den Code dorthin) und blockiert dann, bis der UI-Thread beim abarbeiten seiner Nachrichten diesen Zeiger liest, und den Code auf den der Zeiger zeigt selber ausführt (also das Label aktualisiert). Wenn der UI-Thread das gemacht hat, wird dem anderen Thread der auf das abarbeiten des Synchronize-Blcos wartet gesagt: Lauf weiter. Intern arbeitet das Synchronize auch mit nichts anderem als die oben genannten Mechanismen. Ist alles keine Magie
Sobald Du die Konzepte verstanden hast macht das auf einmal alles Sinn