Hmm..

Zitat von norwegen60:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TthrTest.Execute;
//******************************************************************************************************************************************
begin
  inherited;

  while not Terminated do
  begin
    FSection.Acquire; // Zugriff auf FListe schützen
    try
      if FListe.Count > 0 then
      begin
        Wert := FListe[0]; // ---->> Zugriff auf die Property 'Wert' und somit auf den Setter 'SetWert'
        FListe.Delete(0);
      end;
    finally
      FSection.Release; // Zugriff auf FListe wieder freigeben
    end;
    TThread.Sleep(300);
  end;
end;

procedure TthrTest.SetWert(const Value: String);
//******************************************************************************************************************************************
var
  bChanged: Boolean;

begin
  FSection.Acquire; // Zugriff auf FWert schützen
  try
    bChanged := (FWert <> Value);
    if bChanged then
      FWert := Value;
  finally
    FSection.Release; // Zugriff auf FWert wieder freigeben
  end;

  // Nicht innerhalb der CriticalSection da Main sonst blockieren könnte
  if bChanged then
    Synchronize(SyncEventWert);
end;

Der DeadLock kommt hier deshalb, weil Du innerhalb des Locks im Execute auf den Setter von Wert zugreifst, welcher selber wieder ein Lock machen will...

Dein Synchronize sollte auch nicht im Setter, sondern im Execute gemacht werden..

zusammenfalten · markieren

Delphi-Quellcode:

procedure TthrTest.Execute;
var
  tmpDataToSend : String;
begin
  inherited;

  FWert := '';

  while not Terminated do
  begin
    FSection.Acquire; // Zugriff auf FListe schützen
    try
      if FListe.Count > 0 then
      begin
        FWert := FListe[0];
        FListe.Delete(0);
      end;
    finally
      FSection.Release; // Zugriff auf FListe wieder freigeben
    end;


    // Nicht innerhalb der CriticalSection da Main sonst blockieren könnte
    if FWert <> '' then begin
      Synchronize(SyncEventWert);
      FWert := '';
    end;

    TThread.Sleep(1);
  end;
end;

Deine Property Wert mit seinem Setter ist somit Überflüssig,ja sogar falsch, da deine Liste über 'SendToListe' gefüllt wird und auf FWert nur innerhalb von Execute zugegriffen werden sollte, da dieser nur für Synchronize benötigt wird.

Für den Sleep genügt auch ein Wert von einer MS...

Es ist immer das selbe Problem. Wenn man seinen ganzen Sourcecode ausgeben würde, würde der Code zu kompliziert. Reduziert man ihn auf das (vermeintlich) Wesentliche, sieht der Beispielcode kompliziert aus.

In meinem Fall wird Wert in Wirklichkeit von der RS232 zurück geliefert, über AsyncPro.ComPortTriggerAvail erfasst und dort auch Wert gesetzt. D.h. Exceute bekommt davon gar nichts mit. Deshalb das Synchronize im Setter. Mit deiner Änderung würde Execute nichts mitbekommen wenn ich den Wert über den Button [Write into Wert] vom Main her ändere. Das würde dein Execute nicht erkennen und somit auch nichts an den Main zurück liefern. (In dem Fall simuliert der Button [Write into Wert] den PortTrigger.)

Mit dem Doppel-Lock in meinem Execute-Beispiel hast du recht. Tritt aus vorigen Gründen so im Echtcode aber nicht auf.
Das seltsame: Trotz des Doppellock im Exceute läuft mein ZIP-Beispiel ohne Probleme. Nur der Echtcode nicht. Ich bin dabei den Beispielcode mehr und mehr an meine Realcode ranzubringen.

Den Sleep habe ich so lang gemacht um simulieren zu können, dass sich die Liste auch mal schneller füllt als sie abgearbeitet wird und trotzdem kein Befehl verliert.

Darf Synchronize wirklich nur in Exceute aufgerufen werden

Hmm..

Wenn 'Wert' eh nur direkt gesetzt wird, dann kannst Du auch deinen kompletten Thread wegschmeißen!

Nur wenn dein AsyncPro.ComPortTriggerAvail das 'SendToListe' verwendet, kann die Liste überhaupt funktionieren..
Und nur dann könntest Du den Thread brauchen...

Noch mal: In meinem Beispiel wollte ich die Situation simulieren, dass zwei Threads auf ein und denselben Wert zugreifen. Deshalb wird dieser Wert über Exceute aus der Liste gefüllt als auch über einen Button-Klick aus dem Main-Thread. Dies nur um zu testen, ob ich Konflikte erzeugen kann

Im realen Code sendet der Main Befehle in eine Liste des Thread. Diese Befehle werden in Execute aus der Liste an den ComPort geschickt. Ein neuer Befehl wird aber erst geschickt, wenn der vorherige geantwortet hat. Deshalb das Puffern in der Liste.
Irgendwann antwortet das angeschlossene Gerät und die Antwort wird über das Event ComPortTriggerAvailable so lange gesammelt bis sie komplette ist. Dann wird sie in Wert geschrieben und damit über den Setter an den Main geschickt. Danach kann Executen den nächsten Befehl aus der Lsite auslesen und an den ComPort schicken. Zwischenzeitlich kann der Main aber schon weitere Befehle an die Liste geschickt werden.
Auch wenn der Wert über Synchronize an den Main übergeben wurde, soll es möglich sein, diesen Wert auch manuell abzufrage ohne dass es kracht.