Zuerst:

Du willst keinen Thread der sammelt, noch einen der berechnet!

Da gibt es eine Aufgabe des Sammelns und des Berechnens und diese beiden Aufgaben sollen in einem eigenen Thread-Kontext laufen.

Ist das ungefähr getroffen?

Ganz einfach dargestellt sowas?

zusammenfalten · markieren

Delphi-Quellcode:

TTask.Create(
  procedure
  var
    LData : TDataContainer;
  begin
    while not Aufhören do
    begin
      if DatenGefunden( LData ) then
        TTask.Create(
          procedure
          begin
            Verarbeite( LData );
          end );
    end;
  end );

Vielen Dank für die Hilfe bislang aber nein

Ganz abseits von konkreten Beispielen:

Ich möchte das, was man mit dem TThread.Synchronize(..) und TThread.Queue(..) dem Hauptthread zuwerfen kann, einem x-beliebigen Thread zuwerfen können.


Ein konkretes Beispiel:

Ich habe einen Polling-Thread der einen Zustandwechsel feststellt. Diesen Zustandswechsel von X auf Y soll ein anderer Thread mitbekommen und verarbeiten- Die Reaktion auf den Wechsel soll also nicht im Kontext des Polling-Threads erfolgen. Die Reaktion des Verarbeiters darf auch gerne erst kommen, wenn schon drei weitere Zustandwechsel stattgefunden haben, kein Problem.

Man sieht: Beide Threads existieren bereits und werden das auch die ganze Laufzeit über tun. Der Verarbeiter hat auch noch mehr zu tun als nur darauf mal zu reagieren. Aber die Reaktion muss halt in seinem Kontext geschehen. Genau wie der GUI-Hauptthread der ja üblicherweise auch andere Dinge macht als den Kram dem man ihm mit TThread.Synchronize(..) zuschiebt.

Für so Dinge verwende ich meistens Events (CreateEvent, WaitForSingleObject). Die gibt es in den neueren Delphi Versionen glaube ich auch in einer Klasse gekapselt.

Thread 2 erstellt ein Event und wartet direkt im Execute auf signal. Thread 1 sinalisiert das Event, nachdem die Daten da sind. Thread 2 blockiert nun nicht mehr und bearbeitet die Daten. Wenn Thread 1 während der Bearbeitung weitere Daten hat, werden die ebenfalls an Thread 2 übergeben (hierfür sollte Thread 2 z.b. einen Stream bereitstellen. CriticalSections bei gemeinsamen Zugriff nicht vergessen!). Thread 2 arbeitet dann so lange, bis keine Daten mehr da sind, setzt dann das Event wieder zurück und fängt die Schleife von vorne an.

BTW: Wenn es dir konkret um eine Server Anwendung geht, dann such mal nach IO Completion Ports.

Grade das macht ja nur Sinn wenn der wartende Thread ("Thread 2") sonst keine Aufgabe hat.

Zitat von Der schöne Günther:

Grade das macht ja nur Sinn wenn der wartende Thread ("Thread 2") sonst keine Aufgabe hat.

Naja, wenn Thread 2 permanent irgendwas macht und nur zwischendurch Daten von Thread 1 verarbeiten soll, dann würde ich vermutlich einfach einen Boolean anlegen, der komplett von Thread 1 kontrolliert wird. Die Daten würde ich dann auch im Thread 1 zwischenlagern (Stream, Queue, etc.). Thread 1 schaut nun während seiner permanenten Aufgabe z.b. einmal pro Loop, ob der Boolean true ist und verarbeitet dann 1-n Pakete aus der Queue.

Edit: Ansonsten kannst du auch Events "peeken", indem du das Timeout von WaitForSingleObject auf 0 setzt und den entsprechenden Rückgabewert auswertest.

Man sollte sich einmal die Frage stellen (und beantworten) warum gibt es für den GUI-Thread das Sync und Queue.

Evtl. weil einen die Standard Sync-Methoden (CriticalSection, Event, ...) dort nicht weiterbringen?
Aber die anderen (nicht-GUI-) Threads können mit denen sehr wohl umgehen.

Jetzt nochmal: Wozu ein EnqueueInThread?

Erstell eine Queue, sichere die mit einer CriticalSection und setze den Event. Dann hat man genau das.
Ob diese Queue dann von 1 oder n Threads abgefragt wird ist dann wumpe.

Ja, das führt in diesem Beispielfall mit dem Pollingthread auch zum Ziel. Aber allgemein bringt das noch kein "Wie führe ich X im Kontext von Thread Y aus?". Oder für meinen Kopf ist es heute schon zu spät.

Und warum kann ich bei TThread.Synchronize überhaupt ein anderes TThread-Objekt angeben? Die TThread-Instanzmethode CheckSynchronize springt mit Exception raus wenn sie nicht im GUI-Thread ausgeführt wird

//Edit

Zitat von Zacherl:

Edit: Ansonsten kannst du auch Events "peeken", indem du das Timeout von WaitForSingleObject auf 0 setzt und den entsprechenden Rückgabewert auswertest.

Oh. Gute Idee.

Zacherl war schneller!

Events...

Und eine Queue mit Locking...