Synchronisierung von Subthreads (VCL) + Pointerzugriff

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Delphi-Freak

Aha! Aber gibt es auch was einfacheres, außer jetzt alle Methoden nochmals zu implementieren? Also dass man das gleich für alle Methoden einer Klasse macht? Anscheinend nicht - oder doch :coder2:

Wer hat denn was von Reimplementieren gesagt? :zwinker:

Schnell zusammengetippt und daher mit 100%iger Wahrscheinlichkeit die falschen Bezeichner, aber die kannst du ja in der Online-Hilfe nachschlagen, sieh mir nach, daß ich als Gelegenheits-mit-Delphi-Entwickler nicht alle Klassen der VCL auswendig kenne ;-)

Delphi-Quellcode:

type
  TSomeThread = class(TThread)
    // ...
    private
      FIDIrgendwas: TIDIrgendwas;
  end;

constructor TSomeThread.Create(...);
begin
  inherited;
  FIDIrgendwas := TIDIrgendwas.Create;
end;

procedure TSomeThread.MessageHandler(Message: TMessage); // oder so
begin
  case Message.MsgType of // oder so
    STM_CONNECT
    begin
      FIDIrgendwas.Connect(...);
      // fertig, schicke eine Benachrichtigung an den Hauptthread
    end;

    STM_GET
    begin
      FIDIrgendwas.Get(...);
      // fertig, schicke eine Benachrichtigung an den Hauptthread
    end;
  end;
end;

procedure TSomeThread.Execute(...);
begin
  // Nachrichtenschleife
end;

Und damit die Handler wissen, was zu tun ist, solltest du die die beiden Datenfelder einer Message anschauen. Das sind zwar nur zwei LongWords, aber du kannst einen Pointer zu einem Integer casten, deswegen kannst du beliebig viele Informationen übergeben, indem du einfach einen Record deklarierst, die Daten dort reinpackst und einen Pointer auf den Record an die Nachricht hängst. Casten ist zwar weder schön noch hübsch, aber bei einer C-API, wie Windows nunmal eine hat, leider nicht immer zu vermeiden.

[Delphi-Freak]

Gut, danke!
Und was gehört dann in die Execute-Methode hinein? Ich habe das mal aus einem nonVCL-Proggy herausgekramt, leider aber nicht von mir selber geschrieben :mrgreen:

Delphi-Quellcode:

var
Msg: TMsg;
begin
while GetMessage(Msg, 0, 0, 0) do begin
   TranslateMessage(Msg);
   DispatchMessage(Msg);
end;

Übrigens in der Hilfe zu PostThreadMessage steht folgendes:

Zitat:

Zitat von OH

The system only does marshalling for system messages (those in the range 0 to WM_USER). To send other messages (those above WM_USER) to another process, you must do custom marshalling.

Verstehe ich das falsch, dass man keine Message über WM_USER verwenden kann?

LG, ich

Edit: Tippfehler

[Frickeldrecktuxer_TM]

Zitat:

Zitat von markusj

in meinem Programmkontext macht das Auslagern ganzer Klassen Sinn, damit der Benutzer mit anderen Programmteilen arbeiten kann, während sich meine Thread-Klassen-Hybrid selbst verwaltet und nach der Ausführung auf die nächste Aufgabe wartet ...

Wenn die Klasse selbstverwaltend ist, hast du doch deinen Task, den du in einem Thread ausführen kannst. Wenn die Klasse ein eigenständiger Service ist, kannst du das Verfahren anwenden, daß ich für Delphi-Freak eben beschrieben habe. Das Problem mit einem Kapseln von Threads in eine Klasse ist immer, das dadurch sämtliche Aufrufe asynchron werden und man je nach Bearbeitungsgeschwindigkeit des Aufrufs und des Aufrufers mitunter Probleme kriegt, wenn irgendwer auf Ergebnisse eines anderen angewiesen ist sogar Race-Conditions.
Eine Klasse, bei der jeder Methodenaufruf einen weiteren Thread abspaltet funktioniert einfach nicht ohne weiteres. Was aber geht, ist, durch *manuelle* Synchronisierung lediglich *einen* Thread zu verwenden. Das ist das, was ich eben geschildert habe. Das erfordert allerdings entsprechenden Aufwand, um ein Interface aufzubauen. Und man benötigt immer noch zusätzlichen Kontrollcode. Man lagert also nicht die Klasse (oder den Code der Klasse) in einen Thread aus, sondern man lagert die *Benutzung* in einen Thread aus. Diese Benutzung hat man vorher bereits in seinem einzelnen Haupt-Thread, man lagert also effektiv Code aus diesem Haupt-Thread aus, und lässt nicht einfach Aufrufe in einen Thread münden.
Nimm zum Beispiel einen Code, der aus einem UCS-16LE-Text einen UCS-16BE-Text (16bit pro Zeichen, Little Endianness gegen Big Endianness) macht. Man kann einen TFile-Stream nehmen und, 2 Bytes einlesen, die Reihenfolge tauschen und die 2 Bytes zurückschreiben. Das Lesen und Schreiben, das wahrscheinlich am längsten dauert (falls nicht, macht man's mit 'nem Diskettenlaufwerk, dann dauert's lange :mrgreen:), in asynchronen Aufrufen zu machen, indem man TFileStream entsprechend modifiziert, würde wahrscheinlich schnell sehr viele Threads erzeugen, die alle noch dabei sind, ihre 2 Bytes zu schreiben. Das Resultat wären jede Menge konkurrierende Laufwerkszugriffe, das kann niemand wollen. Stattdessen lagere ich die Benutzung von TFileStream in einen Thread aus, also den gesamten Vorgang: Lesen, Vertauschen, Schreiben. Dadurch sind alle Operationen in "richtiger" Reihenfolge. Aber ich habe nicht die Klasse ausgelagert, sondern die Benutzung.

Zitat:

Zitat von markusj

*einbisschensauer*

War wirklich nicht böse gemeint, aber Klassen und Threads beißen sich nunmal heftig.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Delphi-Freak

Gut, danke!
Und was gehört dann in die Execute-Methode hinein? Ich habe das mal aus einem nonVCL-Proggy herausgekramt, leider aber nicht von mir selber geschrieben :mrgreen:

Delphi-Quellcode:

var
Msg: TMsg;
begin
while GetMessage(Msg, 0, 0, 0) do begin
   TranslateMessage(Msg);
   DispatchMessage(Msg);
end;

Kein TranslateMessage() und kein DispatchMEssage(). Du hast kein Fenster, also kann DispatchMessage() auch keine WndProc aufrufen. Einfach zwischen dem begin und dem end den Handler aufrufen, oder direkt dort mit case die NAchricht verarbeiten.

Zitat:

Zitat von Delphi-Freak

Übrigens in der Hilfe zu PostThreadMessage steht folgendes:

Zitat:

Zitat von OH

The system only does marshalling for system messages (those in the range 0 to WM_USER). To send other messages (those above WM_USER) to another process, you must do custom marshalling.

Verstehe ich das falsch, dass man keine Message über WM_USER verwenden kann?

Das sollte eigentlich nur für Nachrichten über Prozess-Grenzen hinweg gelten, wenn ich mich richtig erinnere.

[Delphi-Freak]

Gut, Danke! :thumb:
Dann sind meine Fragen so weit geklärt...

LG, ich

[markusj]

Ich danke auch ... ich habe aber ein etwas anderes Anwendungsgebiet als Indy

mfG

Markus

PS: So wie du (Frickeldrecktuxer_TM)mir das vorgschlagen hast, hatte ich das auch umgesetzt ... mir ist der Umbau nur praktischer vorgekommen ... hat aer auch Nachteile.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Frickeldrecktuxer_TM

Zitat:

Zitat von Delphi-Freak

Übrigens in der Hilfe zu PostThreadMessage steht folgendes:

Zitat:

Zitat von OH

To send other messages (those above WM_USER) to another process...

Das sollte eigentlich nur für Nachrichten über Prozess-Grenzen hinweg gelten, wenn ich mich richtig erinnere.

War schon spät gestern, hat nix mit meiner Erinnerung zu tun, steht sogar da :mrgreen:

[Delphi-Freak]

Achja, das habe ich übersehen, aber jetzt ist es klar...
Auch wenn es noch immer nicht ganz funktioniert (gibt noch eine AV)... aber das werde ich mir etwas später anschauen; habe gerade meinen Rechner frisch neu aufgesetzt (der Beitrag kommt schon vom neuen System :mrgreen: ). Wahrscheinlich habe ich irgendwo einen Denkfehler eingebaut...

LG, ich