Aufgabe in einen Thread auslagern

[xZise]

Moin,
ich hätte gerne eine Aufgabe in einen Thread ausgelagert. An sich nicht ganz so das Problem, sondern eher, wie bekommt das Fenster heraus, das der Thread fertig wurde? Und als zusätzliches Feature soll das den aktuellen Fortschritt ausgeben (also x % schon fertig), d.h. das der Thread ab und zu das Fenster triggert, das er zu x % fertig ist.

MfG
Fabian

[Bummi]

Sorry bitte löschen, ich hatte nicht gesehen daß es um C# ging

Eine Idee, nur angerissen,
zwischedurch Synchronize(Inform) aufrufen , FStatus als Threadklassenvariable

Delphi-Quellcode:

constructor TMyThread.Create(var CallBack:TCallBack);
begin
  inherited Create(TRUE);
  FCallBack:=CallBack;
  InterlockedIncrement(ScalethreadCount);
  OnTerminate := HandleOnTerminate;
  FreeOnTerminate := True;
end;

procedure TMyThread.Inform;
begin
   if Assigned(CallBack) then CallBack(FStatus);
end;

procedure TMyThread.HandleOnTerminate(Sender: TObject);
begin
  InterlockedDecrement(ScalethreadCount);
  try
  if Assigned(FInform) then FInform(self);
  except end;

end;

[Sir Rufo]

Dabei ist aber zu beachten, dass ein Synchronize den Thread immer ausbremst.

[xZise]

Zitat:

Zitat von Sir Rufo (Beitrag 1054583)

Dabei ist aber zu beachten, dass ein Synchronize den Thread immer ausbremst.

Wenn man es nicht übertreibt und nur jede Sekunde Bescheid sagt ;) Was natürlich am besten wäre, wenn man einfach nur eine Methode triggert und sagt: Der Hauptthread soll diese Methode abarbeiten, danach macht dann der Thread weiter.

MfG
Fabian

PS: Joar in Delphi hätte ich das so gemacht.

[Phoenix]

Das Form hat eine Methode Invoke, der Du einen Delegate mitgeben kannst. Damit kann der Thread dann dem Form seinen status mitteilen und z.b den Balken aktualisieren.

[implementation]

Du könntest eine Variable deklarieren (wo auch immer).
Im Thread aktualisierst du dann immer diese Variable.
Und dann hörst du im Hauptthread Application.Idle ab und überprüfst dort, ob sich die Variable geändert hat.

[Khabarakh]

Es gäbe noch den BackgroundWorker, der das Invoken für dich übernimmt und in zwei hübsche Events packt. Außerdem, äh, kann er auf die Form geklatscht werden :mrgreen: .

@implementation: Naja, solange man im Thread halbwegs einschätzen kann, wann mal wieder der Fortschritt angezeigt werden sollte, ist das eindeutig der leichtere Weg. Und auch wenn es hier nicht gerade um lebenswichtige Daten geht, müsste deine Variable mindestens als volatile gekennzeichnet werden, da sind wir schon wieder tief im Thema Thread-Synchronisierung, das ein reines Invoke meistens umgehen kann.

[SirThornberry]

in delphi-win32 habe ich den Fortschritt in der Regel über PostMessage mitgeteilt. Da stört es auch nicht wenn es mal etwas verzögert ankommt. Wenn der Thread dann fertig ist mit der Arbeit schadet ein syncroner Aufruf zu Form dann auch nicht mehr.

[Khabarakh]

Zitat:

Zitat von SirThornberry (Beitrag 1054618)

in delphi-win32 habe ich den Fortschritt in der Regel über PostMessage mitgeteilt. Da stört es auch nicht wenn es mal etwas verzögert ankommt.

In der BCL laufen sowohl Control.Invoke als auch BeginInvoke über PostMessage, aber grundsätzlich hast du recht: Wenn man nicht explizit auf einen synchronen Aufruf angewiesen ist, ist BeginInvoke eigentlich immer zu bevorzugen. Und warum nicht auch beim letzten Aufruf :gruebel: ?

[SirThornberry]

beim letzten Aufruf würde ich es lassen da ich es schon hatte das der Thread fertig war aber noch nicht alle Postmessages abgearbeitet wurden. Da lief die Progressbar sozusagen schön weiter obwohl der Thread längst fertig war. Wenn ein syncronisierter Aufruf erfolgt läuft zwar die Progressbar nicht mehr bis zum Ende aber dafür läuft sie auch nicht weiter obwohl bereits alles erledigt wurde. (wobei der eigentliche Fehler dann wohl daran lag, zu oft ein PostMessage abgesetzt zu haben)

[Khabarakh]

:gruebel: Egal ob das Completed-Event mit SendMessage oder PostMessage abgesetzt wird, die Message muss sich doch hinter alle Fortschrittsmeldungen einreihen und wird dadurch auch erst abgearbeitet, wenn die ProgressBar schon auf 100% steht. Am Ende eines Threads dürfte es ja wirklich keinen Unterschied mehr zwischen einem synchronen und asynchronen Aufruf geben.

[Sir Rufo]

Der zeitliche Punkt ist dabei entscheidend.

Ein asynchroner Event wird irgendwann abgearbeitet
Ein synchroner zu einem definierten Zeitpunkt

Bei einem asynchronen Event kann es sein, dass das Thread-Objekt gar nicht mehr existiert und dann rummst es

[implementation]

Zitat:

Zitat von Khabarakh (Beitrag 1054610)

@implementation: Und auch wenn es hier nicht gerade um lebenswichtige Daten geht, müsste deine Variable mindestens als volatile gekennzeichnet werden

lock-Blöcke tun's auch :wink:

Code:

// Beim Setzen
lock (fortschritt) fortschritt = ...;

// Beim Lesen
lock (fortschritt) ... = fortschritt;

Wobei sich natürlich darüber streiten lässt, ob lock() beim reinen Lesezugriff überhaupt benötigt wird, aber vorsichtshalber ...