Events in TThread

[DocE]

Hallo miteinander!

Es stellt sich folgende Problematik:

In einem TThread werte ich Audiosignale aus. Hierzu verwende ich in dem Thread eine Komponente, die die Arbeit übernimmt und ein Ereignis auslöst, sobald der Puffer voll ist. Damit die Events überhaupt abgearbeitet werden, muss ich Application.ProcessMessages in einer Schleife aufrufen.

Das Problem ist, dass es dadurch gelegentlich zu Fehlern kommt, wenn ich im Hauptthread z.B. ein Fenster erzeuge. Der häufigste Fehler ist: "Leinwand/Bild erlaubt kein Zeichnen", selbst wenn ich die Übergabe des Threads an den Hauptthread komplett ausschalte, also der Thread für sich alleine läuft.

Nehme ich das Application.ProcessMessages raus, kommt es zu keinem Fehler mehr, allerdings wird auch das Event nicht mehr abgearbeitet. Es ist also davon auszugehen, dass der Hauptthread durch den Aufruf von Application.ProcessMessages irgendwie beeinflusst wird. Scheinbar sind dies aber nur spezielle Events, da ich in vorherigen Tests z.B. die Verarbeitung von Timer-Events im Hauptthread durch den Aufruf von Application.ProcessMessages in einem anderen Thread ausschließen konnte.

Meine Fragen also:

1. Warum kommt es durch den Aufruf von Application.ProcessMessages im TThread zu einem Problem?
2. Wie kann man das ganze umgehen? Ist MsgWaitForMultipleObjects() evtl. eine Lösung?

Nach meinem Verständnis müsste man den Thread irgendwie dazu bringen, in bestimmten Abständen seine eigene MessageQueue abzuarbeiten, nur wie?


Execute sieht also derzeit so aus:

Delphi-Quellcode:

procedure TAudioThread.Execute;
begin

 (...)

  AudioKomponente := TAudioKomponente.Create(nil);
  AudioKomponente.OnBufferFilled := BufferFilled;

 (...)

  AudioKomponente.Start;

  while not Terminated do
  begin

    sleep(100);
    Application.ProcessMessages;

  end;

  AudioKomponente.Stop;
  AudioKomponente.Free;

end;

Vielen Dank schon mal!


Grüsse
...Doc

[chaosben]

Ein Zauberwort heißt "Synchronize" (OH). Damit sollten sich einige Probleme erübrigen.

[xaromz]

Hallo,

NIEMALS Application.ProcessMessages in einem Thread aufrufen!
Wozu auch? Ein Thread läuft ja neben dem Hauptthread, deshalb werden normalen Events auch ganz normal abgearbeitet.

Wenn Du eine Komponente innerhalb eines Threads erzeugst, dann muss auch die gesamte Kommunikation innerhalb des Threads ablaufen. Zeig mal etwas Code, dann kann findet sich bestimmt eine Lösung.

Gruß
xaromz

[Bernhard Geyer]

Zitat von chaosben:

Ein Zauberwort heißt "Synchronize" (OH). Damit sollten sich einige Probleme erübrigen.

Abe ein Synchronize ein einem Thread so eingebaut macht den Thread u.U. vollkommen unnötig.
Es ist evtl. besser den Code er bei Application.ProcessMessages bearbeitet wird einfach nochmal als (lokale) Funktion zu kopieren so das nur Win32-API-Aufrufe stattfinden.

[DocE]

Ich denke Synchronize wird das Problem nicht lösen, denn ich möchte ja gar nichts im Hauptthread ausführen. Das Application.ProcessMessages (bzw. die jetzt gesuchte Alternative) soll ja nur dafür sorgen, dass der Thread seine eigenen Events behandelt.

Die Übergabe an den Hauptthread erfolgt dann unter Verwendung von CriticalSections. Die Übergabe ist aber auch nicht das Problem.

Grüsse
...Doc

[DocE]

Hi Xaromz,

der wichtigeste Teil des Codes ist eigentlich oben gepostet. Die AudioKomponente ruft halt das Ereignis OnBufferFilled auf, sobald der Puffer voll ist. Den Verarbeite ich dann und übergebe ihn ggf. an den Hauptthread.

Das Problem ist ja nur diese Schleife:

Delphi-Quellcode:

  while not Terminated do 
  begin 

    sleep(100); 
    Application.ProcessMessages; 

  end;

In dieser Schleife muss irgendetwas anderes passieren (anstatt Application.ProcessMessages) damit der Thread seine "eigenen" Events, hier: OnBufferFilled der AudioKomponente, bearbeiten kann.

Ohne Application.ProcessMessages passiert gar nichts (keine Bearbeitung des Events).


Grüsse
...Doc

[chaosben]

Zitat von DocE:

denn ich möchte ja gar nichts im Hauptthread ausführen.

Das kann nicht sein. Scheinbar führst du irgendwelche Funktionen aus, die Effekte auf das Aussehen visueller Komponenten haben, die zu dem Hauptthread gehören. Wenn diese "Statusanzeigen" synchronisisert werden, wirst du die damit verbundene Fehlermeldung("Leinwand/Bild erlaubt kein Zeichnen") los und hast trotzdem die Vorteile eines Threads.

Natürlich darfst du nicht die ganze Berechnung synchronisieren, denn dann hätte Bernhard recht.

Und btw.: "BufferFilled" sollte idealerweise eine Prozedur des Threads sein.

[DocE]

Die einzige Aktion die ich im Hauptthread ausführe ist die Übergabe an ein Array. Es wird nichts gezeichnet, geupdatet o.ä. Aber, wie bereits gesagt, ist die Übergabe auch nicht das Problem.

BufferFilled ist eine Prozedur des Threads.

Die Fehlermeldung kommt durch das "Application.ProcessMessages" in der Schleife. Selbst wenn die Übergabe an den Hauptthread komplett herausgenommen wird, kommt es zu dem Fehler "Leinwand/Bild erlaubt kein Zeichnen", wenn z.B. im Hauptthread ein Fenster geöffnet wird.

Ich glaube ich mache mal ein einfaches Beispielprogramm fertig...

[chaosben]

Zitat von DocE:

Ich glaube ich mache mal ein einfaches Beispielprogramm fertig...

[xaromz]

Hallo,

Du erstellst im Thread ein Objekt, das Audiodaten verarbeitet und dabei ab und zu einen Event feuert. Auf diesen möchtest Du innerhalb des Events reagieren.

Sehe ich das richtig?

Wenn ja, dann stellt sich die Frage, wie das Objekt die Audiodaten verarbeitet. Wenn das synchron abläuft, sollte die Lösung ungefähr so aussehen:

Delphi-Quellcode:

type
  TAudioThread = class(TThread)
  private
    procedure OnBufferFilled(Sender: TObject);
  public
    procedure Execute; override;
  end;

implementation

procedure TAudioThread.Execute;
var
  AudioKomponente: TAudioKomponente;
begin
  AudioKomponente := TAudioKomponente.Create(nil);
  AudioKomponente.OnBufferFilled := OnBufferFilled;
  AudioKomponente.Start;
  // hier wird periodisch der Event aufgerufen...
  AudioKomponente.Stop;
  AudioKomponente.Free;
end;

procedure TAudioThread.OnBufferFilled(Sender: TObject);
begin
  Tu irgendwas...
end;

Dadurch, dass die Audiokomponente im Thread aufgerufen wird, läuft sie ja schon neben dem Hauptthread, und der Eventhandler wird im Kontext des Threads aufgerufen.

Wenn hingegen die Audiokomponente asynchron läuft, dann hast Du mit einem Thread ein Problem. Aber dann benötigst Du auch keinen.

Gruß
xaromz