Probleme mit Enter/LeaveCriticalSection

[zagota]

Zitat:

Zitat von Daniel (Beitrag 1348232)

Timer? Doch, geht. Eine CriticalSection blockt zuverlässig alles ab, was da rein will - unabhängig davon, wo es herkommt.

Hab mal eine kleine Demo gebaut(D2010):

Es kommt 2x "enter", das Programm läuft natürlich in einer Endlosschleife.

Wo liegt mein Denkfehler?

Delphi-Quellcode:

var 
  CritcalSection: TCriticalSection;

implementation

{$R *.dfm}

procedure TForm6.Button1Click(Sender: TObject);
begin
  Timer1.Enabled := True;
  CS;
end;

procedure TForm6.CS;
begin
  CritcalSection.Enter;
  try
    OutputDebugString('enter');

    while True do
    begin
      Application.ProcessMessages;
      sleep(100);
    end;

  finally
    CritcalSection.Leave;
    OutputDebugString('leave');
  end;
end;

procedure TForm6.Timer1Timer(Sender: TObject);
begin
  Timer1.Enabled := False;
  CS;
end;

initialization
  CritcalSection := TCriticalSection.Create;
finalization
  CritcalSection.Free;
end.

[Luckie]

Mach es mit Threads und ohne Timer.

[Der schöne Günther]

Ich verstehe die Motivation nicht- das ist doch arg konstruiert. Was bringt das

Delphi-Quellcode:

while True do Application.ProcessMessages()

außer dass du

1. Den Timer aktivierst
2. Deine Methode "CS" aufrufst
3. welches dann endlos Applicaiton.ProcessMessages aufrufst
4. Welches den Timer abarbeiten wird
5. Der Wiederum CS aufruft

[Uwe Raabe]

Application.ProcessMessages arbeitet alle anstehenden Windows-Messages ab. Somit natürlich auch die Button-Clicks und die Timer-Events. Das fürhrt dazu, daß der Timer-Event nochmal aufgerufen wird, obwohl der erste wegen der Endlosschleife noch gar nicht beendet wurde.

Ich vermute mal, du hast mindestens zweimal auf den Button geklickt?

[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:

Zitat von himitsu (Beitrag 1348260)

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:

Zitat von Neutral General (Beitrag 1348277)

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

Ebensowenig wie die Verwendung von Application.ProcessMessages...