Mutithreading: Konsolenausgabe hakt

[iphi]

Ok, hier der Minimalcode, der das Problem zeigt:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;

type
  TPoll = class(TThread)
  private
    { Private declarations }
    POnData  : TNotifyEvent;
  protected
    constructor Create(OnData: TNotifyevent);
    procedure Notify;
    procedure Execute; override;
  end;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private declarations }
    i: integer;
    P: TPoll;
    procedure PData(Sender: TObject);
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

constructor TPoll.Create(OnData: TNotifyevent);
begin
  inherited Create(true);
  Suspended:=false;
  FreeOnTerminate:=true;
  POnData:=OnData;
end;

procedure TPoll.Notify;
begin
if assigned(POnData) then POnData(nil);
end;

procedure TPoll.Execute;

begin
repeat
  sleep(500);
  Synchronize(Notify);
  until terminated;
end;

procedure TForm1.PData(Sender: TObject);
begin
inc(i);
writeln('data packet ',i);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
i:=0;
P:=TPoll.Create(PData);
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
P.Terminate;
end;

end.

Das ist eine ganz normale Delphi7-Fensteranwendung mit einem Fenster (Form1, leer), wobei bei den Linkeroptionen "Generate Console Application" angeklickt sein muss.
Nach meinem Verständniss müsste alle 0,5s eine Zeile auf die Konsole ausgegeben werden. Solange die Maus sich nicht bewegt, bleibt der Thread allerdings unerklärlicherweise stehen und es kommt nix.
Hoffentlich ist die Kristallkugel jetzt überflüssig...

[haentschman]

Moin...
Warum verpaßt du dem Thread nicht ein Event mit den "Arbeitsdaten".

...ungetestet:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs;

type
  TWorkEvent = procedure(Sender: TObject; WorkStep: Integer);

  TPoll = class(TThread)
  private
    FStep: Integer;
    FOnWork: TWorkEvent;
    procedure SyncWork;
  protected
    constructor Create;
    property OnWork: TOnWorkEvent read FOnWork write FOnWork;
    procedure Execute; override;
  end;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    FPoll: TPoll;
    procedure DoOnWork(Sender: TObject; WorkStep: Integer);
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

constructor TPoll.Create;
begin
  inherited Create(True);
  Suspended := False;
  FreeOnTerminate := True;
  FStep := 0;
end;

procedure TPoll.Execute;
begin
  repeat
    sleep(500);
    Synchronize(SyncWork);
    // weitere Steps
  until terminated;
end;

procedure TPoll.SyncWork;
begin
  if Assigned(FOnWork) then
  begin
    FOnWork(Self, FStep);
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  FPoll := TPoll.Create;
  FPoll.OnWork := DoOnWork;
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  FPoll.Free;
end;

procedure TForm1.DoOnWork(Sender: TObject; WorkStep: Integer);
begin
  writeln('data packet ', WorkStep);
end;

end.

[Mavarik]

OK - Du gibst also nicht in ein Consolenfenster aus sondern es IST ein consolen Application?!?

Wofür dann das Form?

Hat ein Consolenprogramm überhaupt einen UI-Thread?

[Uwe Raabe]

Zitat von Mavarik:

Hat ein Consolenprogramm überhaupt einen UI-Thread?

In der Regel nicht. Dafür gibt es eine Abfrage in TApplication.CreateHandle auf IsConsole.

Wenn es lediglich um die Ausgabe geht, würde sich ein separates Form anbieten in dem die Ausgabe erfolgt. Das wäre dann wenigstens konsistent.

Solche Misch-Applikationen haben schon immer für Ärger gesorgt, da sie von Windows überhaupt nicht unterstützt werden (was natürlich manche Leute nicht davon abhält es trotzdem zu machen).

[Mavarik]

Zitat von Uwe Raabe:

(was natürlich manche Leute nicht davon abhält es trotzdem zu machen).

[Der schöne Günther]

Was ist denn da jetzt der Unterschied in den Projektoptionen das zu setzen (habe ich noch nie gemacht)

und zum Test einfach mal mit WinApi.Windows.AllocConsole() ein Konsolenfenster aufzumachen in welches man dann mit WriteLn(..) einfach Dinge reinwirft?

Ich mache das gerne

[himitsu]

Zitat von Uwe Raabe:

(was natürlich manche Leute nicht davon abhält es trotzdem zu machen).

Andersrum geht es problemlos.

Also VCL-Anwendung und da dann selber eine Console anzeigen (AllocConsole)

[haentschman]

Soviel zum Testen...
Korrekt:
TWorkEvent = procedure(Sender: TObject; WorkStep: Integer) of object;

[Blup]

CheckSynchronize wird vom Applikationsobjekt einer VCL-Anwendung regelmäßig aufgerufen.
Dadurch werden Synchronize-Anforderungen von Threads verarbeitet.
In einer Konsolenanwendung muss man selbst für den regelmäßigen Aufruf dieser Methode sorgen.

Bei dieser Methode der Datenübergabe muss sowohl der Threaad als auch die Mainthread seine Arbeit unterbrechen.
Deshalb ist es besser asynchron mit Threads zu komunizieren, allerdings auch etwas aufwendiger.

[iphi]

@ haentschman:

 FPoll.OnWork := DoOnWork; Mein D7-Compiler sagt da:
[Error] Unit1.pas(68): Incompatible types: 'regular procedure and method pointer'

@ Mavarik:

Zitat:

OK - Du gibst also nicht in ein Consolenfenster aus sondern es IST ein consolen Application?!?

Nein, ist sie nicht. Die Konsole habe ich nur zm Debuggen offen.

Zitat:

Wofür dann das Form?

Hab im Beispielprogramm alles bis auf die leere Form rausgeschmissen, da für die Erklärung des Problems unwesentlich.

@ Der schöne Günter:

Zitat:

und zum Test einfach mal mit WinApi.Windows.AllocConsole() ein Konsolenfenster aufzumachen

Hmmm, interessant. Wenn ich mit dieser Variante das Konsolenfenster aufmache, ist das Problem weg.