Thread gegen sich selbst absichern

[DelphiManiac]

Hallo,

ich habe folgendes Problem.
Ich nutze eine Thread (nur den Hauptthread also den GUI-Thread)

Jetzt habe ich eine Procedure: (ist natürlich nur ein Beispiel)

Delphi-Quellcode:

procedure SchreibeLese;
begin
  Schreibe
  Application.ProcessMessages;
  Lese;
end;

Diese Funktion wird nun in einem Timer alle 100 ms aufegerufen.

Jetzt passiert ein Asynchroner Zugriff auf die Procedure über ein ButtonClick.

Wie kann ich sicher gehen, dass die Procedure nie nochmals aufgerufen wird wenn sie gerade aufegerufen worden ist.

Jetzt ist es ja durch das Application.ProcessMessages möglich, dass genau in dem Zeitpunkt (zwischen Schreiben/Lesen)
die Funktion nochmals aufgerufen wird, richtig?

Natürlich könnte man eine Steuervariable verwenden, aber das ist für meinen Fall nicht so gut geeignet.

Gibt es eine Synchronisationsmöglichkeit im eigenen Thread,
CritcalSections sind ja Threadübergreifend...

Hoffe ich habe mich nicht zu unklar ausgedrückt :stupid:

Gruß
DM

//EDIT: Delphi Code Tags vergessen :wall:

[Assertor]

Hi DelphiManiac,

Delphi-Quellcode:

procedure SchreibeLese;
var
  b: Boolean;
begin
  b := MeinTimer.Enabled;
  MeinTimer.Enabled := False;
  Schreibe
  Application.ProcessMessages;
  Lese;
  MeinTimer.Enabled := b;
end;

So würd ich es machen. Damit wird der Timer in Deinem "Thread" für die Dauer des Prozeduraufrufs deaktiviert und nach Fertigstellung auf den ursprünglichen Stand zurückversetzt.

Der Boolean ist nur dafür da, falls Du die Prozedur auch von anderer Stelle aus aufrufst und der Timer gerad nicht läuft. Würde man den immer am Ende anmachen, käme es ja sonst zu Problemen.

Gruß Assertor

Edit: War doch etwas wortkarg ;)

[Luckie]

Deaktivier die Schaltfläche, dann sieht der Bneutzer auch, dass er da jetzt nicht draufklicken kann/darf.

[Assertor]

Zitat:

Zitat von Luckie

Deaktivier die Schaltfläche, dann sieht der Bneutzer auch, dass er da jetzt nicht draufklicken kann/darf.

Das kommt noch dazu. Visuelles Feedback ist was tolles. Das die Anwender das auch immer haben wollen, Tse ;)

Gruß Assertor

[alzaimar]

Threadübergreifend geht eine CriticalSection, aber nicht innerhalb eines Threads...

Ich würde eine Semaphore nehmen und damit die kritischen Teile kapseln:

Delphi-Quellcode:

  TThreadCriticalSection= Class
  private
    fSemaphore: THandle;
  public
    Constructor Create;
    Destructor Destroy; override;
    Procedure Enter;
    Procedure Leave;
  End;


Constructor TThreadCriticalSection.Create;
Begin
  fSemaphore := CreateSemaphore(Nil, 1, 1, Nil);
End;

Destructor TThreadCriticalSection.Destroy;
Begin
  closeHandle(fSemaphore);
End;

Procedure TThreadCriticalSection.Enter;
Begin
  WaitForSingleObject(fSemaphore, INFINITE)
End;

Procedure TThreadCriticalSection.Leave;
Begin
  ReleaseSemaphore(fSemaphore, 1, Nil);  
End;

Dann so:

Delphi-Quellcode:

Procedure TMyClass.MyEvent;
Begin
  MyThreadCriticalSection.Enter;
  Try
    DoExclusiveStuff
  Finally
    MyThreadCriticalSection.Leave;
  End;
End;

@Luckie: Dann blinkt der Button ja ständig. (Timer alle 100ms)

[Assertor]

@alzaimar:

Ist das nicht etwas oversized? Ich habe DelphiManiac so verstanden: Er hat keinen wirklichen Thread, da er vom GUI-Mainthread spricht. Er hat also nur einen Timer, der innerhalb des VCL MainThreads aufgerufen wird.

Gruß Assertor

[alzaimar]

Für Timer würe Dein Ansatz reichen, bei Events allgemein muss man eine Semaphore nehmen (Async Communication z.B.)

[DelphiManiac]

Hi danke für eure Antworten,

also das mit dem einen Button ist natürlich nur ein Beispiel gewesen, eigentlich sind es 20-30.
Und die kann / will / sollte ich auch nicht sperren, ich will ja nur die Prozedur so gestalten,
dass sie im Hauptthread immer vollständig abgearbeitet worden ist, bevor sie erneut aufgerufen wird.
Gruß
DM

[Luckie]

Dann lass das Application.ProcessMessages weg.

[Assertor]

Zitat:

Zitat von Luckie

Dann lass das Application.ProcessMessages weg.

Richtig, aber zusätzlich trotzdem den Timer deaktivieren. Sonst wir die Prozedur ja trotzdem immer wieder aufgerufen...

[DelphiManiac]

Hi,

ja den Timer disable ich und am ende Enable ich ihn wieder.

Das Application.Processmessage rufe ich eigentlich nicht direkt auf, das macht ein Komponente intern,
wenn ich nicht will, dass diese Kompo umgestrickt wird, muss ich dafür ein Workaround machen.

[DelphiManiac]

@alzaimar

Hi, ich habe dein Code mal ausprobiert, leider habe ich jetzt den Effekt, dass die Form einfriert.

Da ja wenn die Funktion WaitForSingleObject aufruft, den kompletten Thread lahm legt richtig?

[alzaimar]

Nein, jedenfalls nicht bei mir, aber vermutlich hast Du einen anderen Anwendungsfall...

WaitForSingleObject wartet, bis der Status der Semaphore <> '0' ist. Sie ist ja mit '1' initialisiert. Also wird der erste aufruf von 'Enter' sofort zurückkehren. Ein zweiter aufruf von 'Enter' hängt dagegen, bis irgendwer 'Leave' aufruft.

Zeig doch mal Deinen Code.

[edit]: In meinem Testfall habe ich im Timer-Event ein Sleep eingebaut, da friert das Formular natürlich auch ein.

[DelphiManiac]

Also folgender Fall.

Die Funktion tritt mit Enter ein
und dann wird Application Processmessages aufgerufen..
Jetzt kommt asynchron eine erneuter Funktionsaufruf (bspw. über einen Button)
Der versucht jetzt auch über Enter einzusteigen (und ruf WaitforSing... auf)

Delphi-Quellcode:

Procedure TThreadCriticalSection.Enter;
Begin
  WaitForSingleObject(fSemaphore, INFINITE)
End;

So nun scheint es so als hätten wir einen Deadlock, da der erste Funktionsaufruf es nicht schaft ein Leave aufzurufen, da
der Thread still steht und darauf wartet...

Vielleicht sehe ich es ja auch falsch..

Danke!

[DelphiManiac]

Wie versprochen mein Beispiel Code:

Delphi-Quellcode:

procedure Test;
begin
  MyThreadCriticalSection.Enter;
  Try
    inc( Counter );
    while not (qbytes= 1000) do
    begin
      Application.ProcessMessages;
      inc(qbytes);
      Sleep(1);
    end;
  Finally
    qbytes:=0;
    MyThreadCriticalSection.Leave;
  End;

  Unit1.Form1.Label1.Caption:=IntToStr(Counter);
end;

procedure TForm1.Timer1Timer(Sender: TObject);
var
  merkeEnabled:Boolean;
begin
  merkeEnabled:=Timer1.Enabled;
  Timer1.Enabled:=false;
  Test;
  Timer1.Enabled:=merkeEnabled;
end;


procedure TForm1.Button1Click(Sender: TObject);
begin
  Test;
end;

[alzaimar]

Ach jetzt hab ich das erst kapiert ... Dieses verflixte 'Application.ProcessMessages'.... stimmt. So ein Mist.

Hmmm... ich glaube, das geht so nur über eine Steuervariable, sodaß ein Versuch, den geschützten Bereich nochmals zu betreten, abgewiesen wird. Ich mach das immer ziemlich billig über die 'Tag' - Eigenschaft des Formulares.

Delphi-Quellcode:

Procedure TMyForm.SomeEvent(Sender : TObject);
Begin
  If Tag<>0 Then Exit;
  Tag := 1;
  Try
    Blabla();
  Finally;
    Tag := 0;
  End;
End;

In meinem Fall wird BlaBla() u.U. wieder den Event 'SomeEvent' auslösen und ich wäre in einer Endlosschleife. So vermeide ich das. Das dürfte in deinem Fall genauso funktionieren.

Ich hab die Sache mit der Semaphore ohne Nachzudenken aus einem Projekt, das bei den konkurrierenden Events ohne ProcessMessages auskommt. Hab gar nicht nachgedacht....

[DelphiManiac]

Ja das verflixte Application.ProcessMessage,

das ist Segen und Fluch zugleich :bounce1: :bouncing4:

Mein Problem ist da dann wenn der Zugriff abgewiesen wird, dann
wird meine Funktion ja nicht ausgeführt...

[Apollonius]

Du kannst doch einfach einen Zähler hochstellen, und in einem Timer (Thread wäre hier wohl zu viel des Guten) dann die Position überprüfen und gegebenenfalls dekrementieren und die Funktion ausführen.

[himitsu]

du könntest ja eine Aufgabenliste in einbauen, da trägt sich die Funktion ein, wenn sie abgewiesen wurde und am Ende der Funktionen wird in der Liste nachgesehn, ob noch was zum Ausführen da ist.

oder wenn es nur ein und die selber Funktion ist, welche sich sperrt, dann halt wie Apollonius schon sagte.

[sirius]

Zitat:

Zitat von DelphiManiac

Natürlich könnte man eine Steuervariable verwenden, aber das ist für meinen Fall nicht so gut geeignet.

Ja, musst du dann auch. Du kannst doch nicht eine elegante Lösong für ein unelegentes Gesamtkonzept fordern. Hast ja selber erkannt: Nimm dieses verdammte Application.Processmessages raus. Das macht dir nur Ärger und ein Workaround dazu dauert länger als bspws. gleich einen separaten Thread zu programmieren.