Zitat von Sir Rufo:

Er hat definitiv einen Thread benutzt, denn sonst macht Terminated und WaitFor keinen Sinn.
[/DELPHI]

Stimmt, das war mir entgangen.

Hier noch der Aufbau und wie es abläuft:

Ich erstelle mir einen ClientThread. Dieser ClientThread hat einen Indy 10 TCP Client.
Der ClientThread überprüft natürlich bei jedem Durchlauf ob der InputPuffer was enthält.

Nach dem Verbinden des TCP Clients kommen viele Daten rein. Der Thread überprüft auch ob der große Ansturm der Daten vorbei ist.
Dies macht er indem er überprüft ob in den letzten 3 Sekunden keine Daten mehr angekommen sind.
Sind die 3 Sekunden noch nicht verstrichen werden die Daten in eine Temp-Tlist gefüttert.
Jedoch ändert sich der Status des Clients bei jedem Empfang (Download/Upload/Anzahl der Daten).
Die Client Informationen sind auch in einem TStringGrid der VCL. Also bei jedem ändern der Daten wird ein Synchronize des Client-TStringgrid gemacht um die Daten in der VCL aktuell zu halten.

Das TStringGrid wird also bearbeitet, dann noch die Spaltenbreite angepasst und dann ein Repaint des TStringGrids durchgeführt. Danach wird ein Application.Processmessage durchgeführt um die VCL nicht einfrieren zu lassen. Die Anzahl der Daten die der Client erhält ist unbekannt. Daher das überprüfen mit den 3 Sekunden.
Erhält der Client jetzt 600 stk Daten wird das Client-TStringGrid mit Synchronize auch 600 mal upgedated um die Info im TStringGrid aktuell zu halten.
Eine Möglichkeit wär, wenn ich statt Application.ProcessMessage den Thread nach dem Synchronize mit einem Sleep still zu legen.
Jedoch führt das dann zu einer Verzögerung zwischen dem Empfang der Daten.

Zitat:

Und wenn das StringGrid ständig mit neuen Daten befeuert wird und dabei ein Neuzeichnen nach sich zieht dann ist die Anwendung ganz schön am kochen.
Wenn im Thread jetzt auch noch jedes Mal Synchronize aufgerufen wird, dann kann ich mir den Thread auch sparen.

Besser wäre es, den Thread die Daten komplett holen zu lassen und dann in einem Rutsch an das StringGrid zu übergeben.

So ähnlich habe ich es bereits. Die erste Flut von Daten wird in eine Temp-TList gegeben. Ist der große Ansturm vorbei wird die Temp-Tlist in die Hauptliste übergeben. Hierführ wird nur einmal Synchronize verwendet da die Liste in einem Schwung hinzugefügt wird.

Jedoch habe ich keine Lösung dafür wie ich die Client Zeile im TStringGrid up to Date halte!?

Edit: Habe nun das Application.ProcessMessage beim Client-TStringGrid rausgenommen. Dafür ein Sleep(0) nach dem Synchronize im Thread. Jetzt kann ich Jederzeit abbreechen ohne das die Anwendung einschläft.
Die VCL reagiert noch. Zwar etwas träge aber ok... Kann man das noch verbessern?

Was meinst Du mit Client-Zeile im TStringGrid? Ist dort eine Angabe zum aktuellen Status Deines TCP-Clients (Download/Upload)?
Falls es so ist, pack das doch in ein Lebel oder ein StatusBar-Panel, das ist immerhin schneller gezeichnet als ein komplettes, möglciherweise randvolles TStringGrid.

Was wird denn übder den Upload geschickt? Auch Daten oder verbirgt sich dahinter die Abfrage ob mehr Daten kommen?

In welchen Abständen kommen Daten an, bzw. gibt es längere Wartezeiten zwischen den einzelnen Datendownloads?

Möglicherweise würde es Dir helfen Up- und Download zu trennen und die entsprechenden Threads über ApplicationEvents zu starten?

Jeder Client hat eine Zeile im TStringGrid.
Jede Zeile hat dann Infos vom Client wie Down/Upload, Verbunden seit, IP, Port.

Die maximale Idle Zeit wo kein TCP Verkehr stattfindet sind so ca. 30s.
Dies ist bedingt durch eine KeepAlive Message.

Zu den Queues:
Um Threads untereinander zu Snchroniseren benutze ich derzeit TThreadList.
D.h. ein Thread füllt Daten in die TThreadList eines anderen Threads.
Beim nächsten Durchlauf überprüft der Thread ob Daten in der TThreadlist Daten vorhanden sind und arbeitet diese dann ab.

Gibt es zu den Queues ein schönes Beispiel oder wie kann man ansonsten einfach Threads untereinander Synchronisieren?

Ich hatte es vorher mit PostThreadMessage versucht, aber bei wenn ein Thread über ca. 300 Nachrichten (in kurzen Zeitabständen) an den anderen Thread geschickt hatte gab es Probleme.

ich empfehle mal folgendes:
http://www.eonclash.com/Tutorials/Mu...ey1.1/ToC.html
http://www.delphipraxis.net/114195-t...huetzen-2.html
http://docwiki.embarcadero.com/CodeE...t_%28Delphi%29

Hatt ja eigentlich nichts mehr mit dem Thema zu tun, aber ich habe jetzt auf Queue umgestellt:

http://www.delphi3000.com/articles/article_3869.asp

Jeder Thread hat nun seine eigene MessageQueue.
Nix mehr mit PostThreadMessage! Läuft schneller und besser!

zusammenfalten · markieren

Delphi-Quellcode:

unit ThreadUtilities;

interface

uses
  Windows, SysUtils, Classes;

type
  TQueueTypes = (
    _TIMER_FINISHED,
    _STOP,
    _START,
    _RESTART
    );

type
  TQueueMessage = record
    Msg : TQueueTypes;
    Value : Integer;
    Data : Pointer;
  end;
  PQueueMessage = ^TQueueMessage;

type
  EThreadStackFinalized = class(Exception);

  // Thread Safe Pointer Queue
  TThreadQueue = class
  private
      FFinalized: Boolean;
      FIOQueue: THandle;
  public
      constructor Create();
      destructor Destroy; override;
      procedure Finalize;
      procedure Put(Data: PQueueMessage);
      procedure CreateMsg(QueueType : TQueueTypes; Data : Pointer = nil; Value : Integer = 0); Overload;
      procedure CreateMsg(QueueType : TQueueTypes; Data : Pointer = nil); Overload;
      procedure CreateMsg(QueueType : TQueueTypes; Value : Integer = 0); Overload;
      function Get(var Data: PQueueMessage): Boolean;
      property Finalized: Boolean read FFinalized;
  end;

implementation

Uses
  uGlobal;

{ TThreadQueue }

constructor TThreadQueue.Create();
begin
  //-- Create IO Completion Queue
  FIOQueue := CreateIOCompletionPort(INVALID_HANDLE_VALUE, 0, 0, 0);
  FFinalized := False;
end;

destructor TThreadQueue.Destroy;
begin
  //-- Destroy Completion Queue
  Finalize;

  if (FIOQueue <> 0) then
      CloseHandle(FIOQueue);
  inherited;
end;

procedure TThreadQueue.Finalize;
begin
  //-- Post a finialize pointer on to the queue
  PostQueuedCompletionStatus(FIOQueue, 0, 0, Pointer($FFFFFFFF));
  FFinalized := True;
end;

(* Pop will return false if the queue is completed *)
function TThreadQueue.Get(var Data: PQueueMessage): Boolean;
var
    A: Cardinal;
    OL: POverLapped;
begin
  Result := True;
  Data := nil;
  if (not FFinalized) then
  //-- Remove/Pop the first pointer from the queue or wait
    //GetQueuedCompletionStatus(FIOQueue, A, Cardinal(Data), OL, INFINITE);
    GetQueuedCompletionStatus(FIOQueue, A, Cardinal(Data), OL, 0);

  //-- Check if we have finalized the queue for completion
  if FFinalized or (Data = nil) then begin
      Result := False;
      //Finalize;
  end;
end;

procedure TThreadQueue.CreateMsg(QueueType : TQueueTypes; Data : Pointer = nil; Value : Integer = 0);
var
  QueueMessage : PQueueMessage;
begin
  New(QueueMessage);
  QueueMessage^.Msg := QueueType;
  QueueMessage^.Value := Value;
  QueueMessage^.Data := Data;
  Put(QueueMessage);
end;

procedure TThreadQueue.CreateMsg(QueueType : TQueueTypes; Data : Pointer = nil);
var
  QueueMessage : PQueueMessage;
begin
  New(QueueMessage);
  QueueMessage^.Msg := QueueType;
  QueueMessage^.Value := 0;
  QueueMessage^.Data := Data;
  Put(QueueMessage);
end;

procedure TThreadQueue.CreateMsg(QueueType : TQueueTypes; Value : Integer = 0);
var
  QueueMessage : PQueueMessage;
begin
  New(QueueMessage);
  QueueMessage^.Msg := QueueType;
  QueueMessage^.Value := Value;
  QueueMessage^.Data := nil;
  Put(QueueMessage);
end;

procedure TThreadQueue.Put(Data: PQueueMessage);
begin
  if FFinalized then
    Raise EThreadStackFinalized.Create('Stack is finalized');
  //-- Add/Push a pointer on to the end of the queue
  PostQueuedCompletionStatus(FIOQueue, 0, Cardinal(Data), nil);
end;

end.