Probleme mit Enter/LeaveCriticalSection

[Mavarik]

Zitat:

Zitat von noisy_master (Beitrag 1348274)

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:

Zitat von noisy_master (Beitrag 1348274)

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:

Zitat von stahli (Beitrag 1348299)

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"...

[stahli]

Ich habe das nochmal ein wenig umgebaut.

Hier wird ProcessMessages 20 mal ausgeführt und dann 20 mal nicht mehr.
Dann wird der Timer ausgeschaltet und dadurch die ersten 20 Logs "nachgeholt".

(Anbei Projekt für XE3 + Exe)




EDIT:

Noch eine kleine Änderung:

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
var
  I: Integer;
  S: string;
begin
  if (Memo1.Lines.Count > 40) then
    Timer1.Enabled := False;
  inc(FCount);
  Memo1.Lines.Add(IntToStr(FCount) + ' ' + FormatDateTime('zzz', Now) + ': ');
  for I := 0 to 20 do
  begin
    Sleep(100);
    if Timer1.Enabled then
      S := '+'
    else
      S := '-';
    Memo1.Lines[Memo1.Lines.Count - 1] := Memo1.Lines[Memo1.Lines.Count - 1] + ' ' + IntToStr(Memo1.Lines.Count) + S +
      IntToStr(I);

    if (Memo1.Lines.Count < 20) then
      Application.ProcessMessages;

  end;
  dec(FCount);
end;

So sieht man, dass der Rest noch abgearbeitet wird, während der Timer schon deaktiviert ist.

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1348361)

Ich habe das nochmal ein wenig umgebaut.

Hier wird ProcessMessages 20 mal ausgeführt und dann 20 mal nicht mehr.
Dann wird der Timer ausgeschaltet und dadurch die ersten 20 Logs "nachgeholt".

(Anbei Projekt für XE3 + Exe)

OK, aber wofür? BZW. was willst Du erreichen? Ich verstehe den Sinn des Timers nicht...

[stahli]

In Deinem Test kommt das Programm nie dazu, die zurückgestellten Aufgaben abzuarbeiten. Es hängt sich letztlich auf und lässt sich nicht beenden.

Mein Test zeigt (besser), dass die zurückgestellten Logs später noch abgearbeitet werden (nämlich wenn keine weiteren ProcessMessages mehr dazwischen funken).

Ist ja nicht weiter wichtig, aber führt vielleicht schneller zur Erleuchtung bei denjenigen, die sich mal damit auseinander setzen wollen.

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1348424)

In Deinem Test kommt das Programm nie dazu, die zurückgestellten Aufgaben abzuarbeiten. Es hängt sich letztlich auf und lässt sich nicht beenden.

Mein Test zeigt (besser), dass die zurückgestellten Logs später noch abgearbeitet werden (nämlich wenn keine weiteren ProcessMessages mehr dazwischen funken).

Ist ja nicht weiter wichtig, aber führt vielleicht schneller zur Erleuchtung bei denjenigen, die sich mal damit auseinander setzen wollen.

hmm - das Problem ist - der Ansatz ist falsch... :stupid:

Ich logge per Thread in einen Queue, damit mein Hauptprogramm durch Threading angehalten wird...
Aus dieser Queue schreibe ich dann aus einem Thread per Queue nicht syncronize auf die UI.

[p80286]

Zitat:

Zitat von Mavarik (Beitrag 1348430)

Ich logge per Thread in einen Queue, damit mein Hauptprogramm durch Threading angehalten wird...
Aus dieser Queue schreibe ich dann aus einem Thread per Queue nicht syncronize auf die UI.

Bisher habe ich mitgelesen und dachte ich hätte das ursprüngliche Problem verstanden, jetzt hab ich einen Knoten im Hirn.

Gruß
K-H

[stahli]

Huch!?

Ich habe Dein Beispiel aus #24 nachgebaut und mich anweisungsgemäß gewundert. :mrgreen:
Dort hast Du einen Timer benutzt, von Threads ist dort nichts erkennbar.

Ich habe die Demo etwas erweitert, damit man noch besser sieht, dass Application.ProcessMessages die Timer-Behandlung unterbricht und rekursiv aufruft.

Du hast doch damit angefangen!!! :stupid:
(ich habe das nur etwas erweitert)


Das Eingangsproblem war doch, dass die erwartete serielle Abarbeitung trotz CS nicht funktionierte. Es ist m.E. ersichtlich geworden, dass dies durch Application.ProcessMessages verursacht ist.


EDIT: Man könnte natürlich das Beispiel noch um Threads und eine CriticalSection erweitern um die Ausgangssituation noch genauer nachzubilden, aber ich denke, das ist nicht unbedingt nötig.