Ein solcher Lock könnte so aussehen:
Delphi-Quellcode:
Flag := False;
while (not Flag) do;
Der Mainthread macht ungefähr so etwas:
Delphi-Quellcode:
repeat
TastaturAbfragen;
MausAbfragen;
EreignisseAbfragen;
ControlsZeichnen;
ProgrammCodeAusführen;
until WennProgrammGeschlossen
ProgrammCodeAusführen reagiert z.B. mal auf das Klicken eines Buttons oder auf das Feuern eines Timers.
Wenn ProgrammCodeAusführen lange dauert, dann kann der Rest erst mal auch nicht mehr erfüllt werden und das Programm "hängt".
Wenn Du im Mainthread o.g. Lock verwendest kommt das Programm nie mehr raus, da Flag nie auf True gesetzt werden wird.
Ohne nebenläufige Threads, die das Flag wieder umschalten, kann man so etwas also nicht umsetzen.
Ich hoffe, dass das nicht ganz falsch ist (wenngleich natürlich stark vereinfacht).
Eine Überlegung zum ProcessMessages:
Wenn im ProgrammCodeAusführen Application.ProcessMessages aufgerufen wird, werden unbehandelte Messages abgearbeitet.
Dazu wird ProgrammCodeAusführen unterbrochen und ggf. rekursiv erneut aufgerufen.
Ist das so richtig?
Insofern dürften die Timer im Beispiel die Logs nicht mehr durcheinander bringen, wenn man das ProcessMessages weg lässt, da sich die Timerbehandlungen dann immer schön in den Kreislauf des Mainthreads einfügen und kein rekursiver Aufruf erfolgen kann.
Richtig? (Ich kann das jetzt nicht testen)