Probleme mit Enter/LeaveCriticalSection

[himitsu]

Zitat:

Im Timer funktioniert nicht

Ums nochmal ordentlich zu erklären:
Wenn alles in TTimern ist, dann läuft alles im Hauptthread
und da eine CriticalSection mehrfache Zugriffe vom selben Thread erlaubt, wird auch alles durchgelassen.
Das ist, damit ein Thread sich nicht selber sperrt, wenn er mehrmals durch die selbe CS will/muss.

* Also entweder keine Timer/Messages verwenden und Zugriffe aus unterschiedlichen Threads
* oder eine andere Sperre verwenden, welche nicht threadaffine arbeitet.

System.SyncObjs.pas (TMonitor, TCriticalSection, TMultiReadSingleWriter und Co. arbeiten threadaffine)


PS: Man kann auch den Button deaktivieren, so lange das OnClick arbeitet. (ist nur bissl unschön, wenn der Button fukusierbar ist und der Bokus danach wo anders steht)

[Mavarik]

Wenn Du CS aufgerufen hast, kommst Du da nie wieder raus...

Da die CS den Main-Thread blockt du aber mit dem Button Klick im Main Thread bist,

kannst Du X-Mal den Button drucken und er wird immer wieder reinlaufen und noch eine CS auf den Stack packen.

[zagota]

Zitat von himitsu:

Zitat:

Im Timer funktioniert nicht

Ums nochmal ordentlich zu erklären:
Wenn alles in TTimern ist, dann läuft alles im Hauptthread
und da eine CriticalSection mehrfache Zugriffe vom selben Thread erlaubt, wird auch alles durchgelassen.
Das ist, damit ein Thread sich nicht selber sperrt, wenn er mehrmals durch die selbe CS will/muss.

* Also entweder keine Timer/Messages verwenden und Zugriffe aus unterschiedlichen Threads
* oder eine andere Sperre verwenden, welche nicht threadaffine arbeitet.

Das kann ich nur bestätigen.
Der Threadersteller hat ein Mix aus Threads und Timer(n) und versucht es mit einer CriticalSection zu syncronisieren und das ist keine gut Idee.

[noisy_master]

Hallo zusammen,

aber ich dachte immer ein onTimer macht einen eigenen Thread auf, oder habe ich da jetzt was falsch verstanden?

Und welche locks arbeiten NICHT "threadaffin"?

[Neutral General]

Timer laufen im Hauptthread und funktionieren über Windows-Messages (WM_TIMER) genau wie Button-Klicks o.ä.
D.h. zwei Timer können auch dementsprechend NIE gleichzeitig laufen, weswegen du keine Critical Section brauchst wenn du nur Timer benutzt.

Bei Threads brauchst du Critical Sections. Und beides zu mischen ist wie schon gesagt keine gute Idee.

[Uwe Raabe]

Zitat von Neutral General:

Und beides zu mischen ist wie schon gesagt keine gute Idee.

Ebensowenig wie die Verwendung von Application.ProcessMessages...

[Mavarik]

Zitat von noisy_master:

Hallo zusammen,

aber ich dachte immer ein onTimer macht einen eigenen Thread auf, oder habe ich da jetzt was falsch verstanden?

Und welche locks arbeiten NICHT "threadaffin"?

ähhh NEIN

TimerOnTimer Aufrufe sind immer im Mainthread

[Uwe Raabe]

Zitat von noisy_master:

Und welche locks arbeiten NICHT "threadaffin"?

Es gibt keine! Ein solcher Lock wäre entweder unnötig oder würde den Thread zum Stillstand bringen. Überleg doch mal - wie sollte das gehen?

[stahli]

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)

[Mavarik]

Zitat von stahli:

Richtig? (Ich kann das jetzt nicht testen)

Ja...

Beispiel:

Delphi-Quellcode:

procedure TForm189.Button1Click(Sender: TObject);
begin
  Timer1.Enabled := true;
end;

procedure TForm189.FormCreate(Sender: TObject);
begin
  FCount := 0;
  Timer1.Interval := 25;
end;

procedure TForm189.Timer1Timer(Sender: TObject);
begin
  Memo1.Lines.Add(FCount.ToString);
  inc(FCount);
  Sleep(100);
//  Application.ProcessMessages;
  dec(FCount);
end;

Einfach mal Application.Processmessage rein nehmen und "wundern"...