AsyncCalls 2.21 - Inlined VCL/Main Thread Synchronisierung

[jbg]

Wer kennt das nicht. Wenn man mit Threads arbeitet und auf die VCL zugreifen möchte, muss man eine Hilf-Methode schreiben, die dann per Synchronize() aufgerufen wird. Dabei müssen die ganzen Parameter in Felder des Thread-Objekts geschrieben werden, damit sie in der synchronisierten Methoden zur Verfügung stehen.
Dies führt dazu, dass man den Programmfluss nicht ganz so einfach folgen.

Mit AsyncCalls kann man das ganze Problem anders angehen, da dort "inlined VCL synchronization" implementiert ist.

Delphi-Quellcode:

procedure TMyThread.Execute;
var
  S: string;
  I: Integer;
begin
  for I := 0 to 100 do
  begin
    // ...

    { ProgressBar aktualisieren }
    S := IntToStr(I) + '%';
    EnterMainThread;
    try
      Label1.Caption := S;
      ProgressBar1.Position := I;
    finally
      LeaveMainThread;
    end;
  end;
end;

AsyncCalls ermöglicht aber noch mehr. So kann man eine Funktion in einem anderen Thread ablaufen lassen.

Delphi-Quellcode:

procedure MyProc(S: string);

  procedure WorkerThread;
  var
    I: Integer;
  begin
    // Thread beschäftigen
    for I := 0 to 1000000 do
      S := S + ' '; // Zugriff auf S aus der umgebenden Funktion
  end;

var
  a: IAsyncCall;
begin
  a := LocalAsyncCall(@WorkerThread);
  DoSomethingTimeConsuming;
  a.Sync; // ab hier muss S fertig "berechnet" sein
  DoSomething(S);
end;

Homepage, Beschreibung, Download

[mkinzler]

Du machst einem ja Angst :zwinker: in welchem Tempo du Fehler/Beschränkungen von Delphi aus dem Weg räumst

[jbg]

Zitat:

Zitat von mkinzler

Du machst einem ja Angst :zwinker: in welchem Tempo du Fehler/Beschränkungen von Delphi aus dem Weg räumst

Naja, der Code für "inlined VCL/main thread synchronization" lag schon lange herum. Nur hatte ich noch Probleme mit dem Exception-Handling, die ich aber nun beheben konnte.

[Bernhard Geyer]

Zitat:

Delphi 5 and 6 aren't supported anymore

:-( Im moment haben wir noch D6 im einsatz (hoffen in den nächsten monaten nach D2007 welcheln zu können). Kannst du mir einen Tipp geben ob ich es doch noch für D6 zum laufen bringen könnte?

Ansonsten :thumb:

[jbg]

Du müsstest dafür einen Ersatz für TThread.StaticSynchronize finden und dann mit Hilfe des "WakeMainThread: TNotifyEvent" event handlers das "SyncEvent: TEvent" nachbauen.
Delphi 5 ist schon wegen seiner Thread-Architektur nicht zu gebrauchen.

[jbg]

Ich habe mir jetzt doch die Mühe gemacht und die fehlende Delphi 6 Funktionalität weitgehends nach implementiert. Aber Delphi 5 werde ich nicht mehr unterstützen können. Das Synchronize von Delphi 5 ist nun mal ganz anders aufgebaut.

[mkinzler]

Das ist ein Service :thumb:

[jbg]

Zitat:

Zitat von mkinzler

Das ist ein Service :thumb:

Nein. Mir ist heute nur langweilig.

[Bernhard Geyer]

Zitat:

Zitat von jbg

Ich habe mir jetzt doch die Mühe gemacht und die fehlende Delphi 6 Funktionalität weitgehends nach implementiert.

Many Thanks :thumb:

[jbg]

Da war ich gestern einfach zu euphorisch nachdem ich das Exception-Handling Problem gelöst hatte und habe ganz übersehen, dass der Compiler das Self so gerne in das EBX Register legt. Dieses wird natürlich beim Thread-Switch durch einen anderen Wert ersetzt und Crash.

Die neue Version 2.01 rettet das EBX, EDI und ESI Register nun in den synchronisierten Code herüber.

Homepage, Beschreibung, Download

[gsh]

cool das kann ich in meinem aktuellen Projekt sicher gut gebrauchen ... Danke :thumb:

[himitsu]

jupp, nettes Teil :shock:

zum ASM: laut Microsofts/Intels Definition dürfen ESP EBP EDI ESI EBX nicht verändert werden, bzw. müssen wiederhergestellt werden (also nicht nur Delphi vereinnahmt das EBX)

[jbg]

Zitat:

Zitat von himitsu

zum ASM: laut Intels Definition

Du meinst wohl laut "Microsofts Definition". Denn das OS gibt die Register-Reservierung vor und nicht der Prozessor.


Ich werde heute Abend übrigens die Version 2.1 herausbringen, die noch weniger Einschränkungen bzgl. der im MainThread-Block verwendeten Anweisungen hat (man sollte im Moment kein "Exit;" einbauen) und bei der auch das Exception-Handling für Delphi 6, 7, und 2005 funktioniert.

[jbg]

Ich habe soeben die Version 2.2 herausgegeben. Dieser behebt alle mir bekannten Bugs und unterstützt auch wieder Delphi 5 und 6.

Download siehe erste Seite (erster Eintrag)

[mkinzler]

:thumb:

[jbg]

Da war doch glatt noch ein Bug in der AsyncMultiSync() Funktion enthalten. Es gibt nun die Version 2.21.

[stoxx]

eine richtig schicke Idee!

2 Fragen ...

1.Frage .. Was vermutest Du, wieviel Änderungen vorraussichtlich notwendig werden, wennn GodeGear mal auf 64 Bit umstellen sollte?
Oder könnte es auch so einfach weiterhin funktionieren. Wahrscheinlich nicht, oder?

2. Frage .. hast Du es ausgiebieg mit 3 oder 4 Thread getestet, dass sich da auch nix verhakt? falls EnterMainThread schon aufgerufen wurde, und nun von einem weiteren Thread nochmal aufgerufen werden soll?

vielen Dank nochmal!
So kann man sehr flexibel ab und an mal was sichtbares anzeigen. Und muss nicht ständig alle ThreadEvents mit Synchronize aufrufen.

[mkinzler]

Vielleicht ist es die Delphi Threading Library ( DPL) bis dahin ja fertig

[himitsu]

ja also, dann will ich och ma was sagen ... nett :thumb:

ok, hab zwarauch schon dieses ganze Synchronize- und zeugs Mithilfe 'nem kleinen Locked-Byte umgangen, aber hiermit könnte man Einiges hübscher lösen :-D



PS: Delphi Threading Library ( DPL ) ?

[DeddyH]

[OT] Vielleicht meint er Delphi Phishing Library :lol: [/OT]

[Bernhard Geyer]

Delphi Parallel Library

[OT]aber die Phishing-Library ist kein schlechter name. Damit hätte Delphi einen Zielmarkt den mitsicherheit kein normaler IDE/Frameworkhersteller bedienen will :mrgreen: [/OT]

[mkinzler]

Ein paar Blogeinträge zur DPL (Delphi Parallel Library)
http://blogs.codegear.com/abauer/2008/01/17/38849
http://blogs.codegear.com/abauer/2008/01/18/38850
http://blogs.codegear.com/abauer/2008/02/06/38855
http://blogs.codegear.com/abauer/2008/02/19/38856
http://blogs.codegear.com/abauer/2008/02/22/38857

[himitsu]

ok, dann wäre das auch geklärt ... mir waren ja nur die Buchstaben T<>P irgendwie nicht zusammenpassend genug :mrgreen:

[jbg]

Zitat:

Zitat von stoxx

1.Frage .. Was vermutest Du, wieviel Änderungen vorraussichtlich notwendig werden, wennn GodeGear mal auf 64 Bit umstellen sollte?

Der Assembler-Code müsste angepasst werden, da die Register dann 64 Bit breit sind. Das dürfte aber eine Arbeit von Minuten sein. Aber da es noch kein Delphi 64bit gibt, kann ich das ja schlecht schon programmieren.

Zitat:

2. Frage .. hast Du es ausgiebieg mit 3 oder 4 Thread getestet, dass sich da auch nix verhakt? falls EnterMainThread schon aufgerufen wurde, und nun von einem weiteren Thread nochmal aufgerufen werden soll?

Das ganze ist schon abgesichert durch Critical Sections. Zudem wird intern bei EnterMainThread/LeaveMainThread auch nur mit Wasser gekocht und TThread.Synchronize aufgerufen.

[mkinzler]

War auch nicht als 1:1 Abkürzung gedacht.

[gsh]

So hab das jetzt in meinem projekt eingebaut und ich muss sagen :thumb:
Bin sehr zufrieden damit

Danke jbg

[grefab]

Sehr nette Sache! Eine Frage habe ich aber: Ist es möglich, Threads (oder die darin ausgeführten Prozeduren) "mit Gewalt" abzubrechen? Kann ja sein dass das Programm "unterwegs" feststellt, dass die asynchrone Berechnung nicht mehr gebraucht wird, weil sich irgendwas geändert hat und sie eh neu angeworfen werden muss. Dann würde ich gerne den Thread abwürgen und nochmal neu beginnen, ohne das überflüssige Resultat abwarten zu müssen. Könnte allerdings ressourcenfreigabetechnisch stressig werden...

Ich würde jetzt ab und an eine Flagabfrage z.B. in die Ausführungsschleife einbauen. Eleganter wäre es aber, wenn das der "Auftraggeber" der asynchronen Ausführung regeln könnte.

[Zacherl]

Funktioniert das ganze auch in mittels CreateThread oder BeginThread erzeugten Threads? Weil du geschrieben hattest, dass letztendlich doch nur die Synchronize Funktion des TThread Objektes aufgerufen wird.

[jbg]

Zitat:

Zitat von grefab

Könnte allerdings ressourcenfreigabetechnisch stressig werden...

Nicht nur das. Wenn du den Thread innerhalb einer CriticalSection abwürgst, bekommst du beim nächsten Start des Threads einen Deadlock.

Zitat:

Ich würde jetzt ab und an eine Flagabfrage z.B. in die Ausführungsschleife einbauen. Eleganter wäre es aber, wenn das der "Auftraggeber" der asynchronen Ausführung regeln könnte.

Und genau das sollte man nie machen. Man kann nur beim Thread anfragen, dass dieser sich beenden soll, denn nur er weiß wann es sicher ist, sich zu beenden.

[jbg]

Zitat:

Zitat von Zacherl

Funktioniert das ganze auch in mittels CreateThread oder BeginThread erzeugten Threads? Weil du geschrieben hattest, dass letztendlich doch nur die Synchronize Funktion des TThread Objektes aufgerufen wird.

Wie meinst du das? TThread.StaticSynchronize ist eine Klassenmethode, die man auch außerhalb eines TThread Objekts ausrufen kann.

[Zacherl]

Zitat:

Zitat von jbg

Zitat:

Zitat von Zacherl

Funktioniert das ganze auch in mittels CreateThread oder BeginThread erzeugten Threads? Weil du geschrieben hattest, dass letztendlich doch nur die Synchronize Funktion des TThread Objektes aufgerufen wird.

Wie meinst du das? TThread.StaticSynchronize ist eine Klassenmethode, die man auch außerhalb eines TThread Objekts ausrufen kann.

Ahso okay, damit hat sich meine Frage schon erledigt :)