Hallo
ich bin grade dabei ein Program zu schreiben das während seiner Ausführung unter anderem auch einige FTP Transfers durchführt. Hierfür benutze ich die Indy ftpclient Komponente. Damit mein Program während des Transfers noch etwas anderes machen kann hab ich den "ftp-code" in einen extra Thread ausgelagert. Die execute methode des ftp threads sieht so aus:

zusammenfalten · markieren

Delphi-Quellcode:

begin
  while not Self.Terminated do
  begin
    case nextaction of
      1:connect;
      2:disconnect;
      3:get;
      4:exit;
    end;
  end;
end;

Die procedures connect, disconnect, get und exit machen jeweils das was in ihrem Namen steht, setzen das event fertig und legen den Thread mit suspend schlafen.
Im Hauptthread wird dann folgendermassen mit dem ftp Thread gearbeitet

zusammenfalten · markieren

Delphi-Quellcode:

   ...
  ftp:=Tftthread.Create(true);
  ftp.nextaction:=1; // Aktion 1
  ftp.Resume;
  // do something
  while not ((fertig.WaitFor(150))= wrSignaled)do
  begin
    Application.ProcessMessages;
  end;
  fertig.resetevent;
  ...
  ftp.nextaction:=3; // Aktion 2
  ftp.Resume;
  // do something
  while not ((fertig.WaitFor(150))= wrSignaled)do
  begin
    Application.ProcessMessages;
  end;
  fertig.resetevent;
  ...

Das Problem ist nun das wenn Aktion 2 unmittelbar auf Aktion 1 folgt der Hauptthread endlos in der while Schleife wartet. Auch ein Brakepoint in der get procedure des ftp Threads wird nie angespungen. Setze ich aber in der connect procedure einen Brakepoint und lasse das Programm sofort weiterlaufen funktioniert alles. Die Anzeichen deuten auf ein timing Problem, nur kann ich leider keins erkennen.

Glückwunsch, du hast herausgefunden warum das Arbeiten mit Threads nicht-trivial ist. Du hast Deadlocks erzeugt. Was ich dir raten kann ist, deine komplette Architektur zu überdenken. Denn du mischst hier blockierend und nichtblockierend ...

Beispiel: niemand hindert dich für jeden Request einen neuen Thread (i.e. neue Instanz deiner Threadklasse) zu erzeugen. Du arbeitest hier scheinbar statisch mit einem Thread. Es wäre beispielsweise möglich, daß du 3 Typen (Klassen) von Threads definierst, welche für jeweils eine Aktion zuständig sind. Dann übergibst du dem ersten Thread in der Reihe ein Objekt (oder Struktur) in der Statusinfos gespeichert sind. Beispielsweise würde ich dort das Hauptfenster-Handle speichern, eine Critical Section sowie andere Infos die für dich wichtig sind (wo in meiner Abarbeitung bin ich).

Bspw. Klassen:
- TConnectThread
- TDisconnectThread
- TGetThread

Jeder dieser Threads darf 2 Integers als Statusinformation via PostMessage an das Hauptfenster schicken, so daß du den aktuellen Status anzeigen kannst ohne den Thread anhalten zu müssen. Hat ein Thread seine Aktion erledigt, gibt er die Struktur an den nächsten Thread (connect -> disconnect -> get) weiter.

Am besten solltest du aber die Anzahl der Threads jeder Klasse begrenzen um sicherzustellen, daß es keine Probleme gibt. Dazu hältst du einen Ringpuffer mit deinen Strukturen und jede der Strukturen hat (Critical Section o.ä.) ein Lock. Sobald ein nueer Request eintrifft, wird das Lock gehalten und erst die letzte Threadklasse kann das Lock freigeben. Die Übergabe der Requests muß dann natürlich über eine Art Dispatcher-Thread erfolgen, damit du nicht schon beim Einreihen wieder unfreiwillig blockierst.