Vor einigen Monaten bin ich auf ein größeres Problem des TThread-Objektes im Zusammenhang mit der
RTL gestoßen. Ruft man die Suspend-Methode des Threads auf, um seine Arbeit vorrübergehend zu unterbrechen, kann daraufhin das gesamte Programm einfrieren.
Es tritt dabei ein sog. Deadlock auf: Der Thread wartet darauf, dass er wieder geweckt wird, während der Hauptthread auf etwas wartet, das der wartende Thread beenden muss. In diesem Zustand reagiert die Applikation auf keine Anforderungen von außen mehr, es ist eingefroren.
Der Grund? Der Thread befindet sich in einer Critical Section, die vom Hauptthread auch betreten werden will, während der Thread schon schläft.
Critical Section? Was ist das? Eine Critical Section (CS) dient dazu, von mehreren Threads gemeinsam genutzte Ressourcen (z.B. ein Speicherbereich) zu verwalten. Vor dem Zugriff darauf ruft man EnterCriticalSection auf, danach LeaveCriticalSection. Über den Scheduler von Windows wird nun dafür gesorgt, dass sich niemals zwei Threads gleichzeitig in der selben CriticalSection befinden können, sondern erst darauf warten, dass sie wieder verlassen wird.
Nie gehört, benutze ich auch gar nicht. Doch! Die
RTL benutzt intern bei jedem Aufruf von GetMem und FreeMem die Critical Section heapLock (zu finden in getmem.inc) - und damit immer, wenn eine dynamische Variable reserviert oder freigegeben wird. Dazu gehören auch Strings.
Mein Beispielprojekt dazu erzeugt einfach einen Thread, der pausenlos GetMem und FreeMem aufruft. Per Knopfdruck lässt er sich suspenden und resumen, und per Knopfdruck lässt sich im Kontext des Hauptthreads ebenfalls GetMem und FreeMem aufrufen. Suspended man nun den Thread und ruft GetMem oder FreeMem auf, friert das Programm mit großer Wahrscheinlichkeit komplett ein.