ThreadPool 1.0.9 für Delphi 2010-XE

[WladiD]

Nachdem ich vergeblich nach einem Open-Source Thread-Pool für Delphi gesucht habe, welches meine Bedürfnisse abdeckt, musste ich mich dafür entschließen, einen eigenen zu schreiben. Diesen möchte ich euch hier vorstellen.

Vereinfacht kann man die Funktionsweise des ThreadPools wie folgt beschreiben:

Man verbindet sich aus einem beliebigen Thread mit dem spezifischen Manager (welcher ebenfalls ein eigenständiger Thread ist) und übergibt ihm eine Aufgabe. Der Manager übergibt die Aufgabe an einen neuen bzw. schlafenden Arbeiter oder packt sie auf die Warteliste, wenn bestimmte Grenzwerte es nicht zulassen die Aufgabe sofort abzuarbeiten. Der Arbeiter nimmt sich der Aufgabe an, arbeitet sie parallel ab und meldet sich über synchronisierte Ereignisse, wenn er fertig ist. Hat der Manager noch weitere Aufgaben anliegen, so bekommt der Arbeiter sofort den Nächsten. Sind alle Aufträge abgearbeitet, so kann der Manager eine bestimmte anzahl an Arbeitern schlafen legen (SpareWorkersCount) und die restlichen Arbeiter werden terminiert.


Hauptmerkmale

• Manager und Arbeiter sind eigenständige Threads
  
  
• Ein spezifischer Pool wird von den Basis-Klassen TPoolManager, TPoolWorker und TPoolTask abgeleitet, wobei nur wenige Methoden mit "Leben" gefüllt werden müssen.
  
  
• Für jeden abgeleiteten TPoolManager wird (nur) bei Bedarf eine eindeutige Instanz erstellt (verborgenes Singleton pattern)
  
  
• Die genaue Instanz eines spezifischen Managers ist unbekannt und muss über eine Verbindung mittels TMyPoolManager.Connect oder TMyPoolManager.Bind ermittelt werden
  
  
• Der Manager erstellt die Arbeiter gemäß der Auftragslage dynamisch unter berücksichtigung einer definierbaren Obergrenze (TMyPoolManager.ConcurrentWorkersCount)
  
  
• Die Arbeiter-Threads werden wiederverwendet. Das heißt, ist ein Arbeiter fertig und es liegen weitere Aufträge an, so bekommt er sofort den Nächsten.
  
  
• Anzahl an schlafenden Arbeitern kann über TMyPoolManager.SpareWorkersCount definiert werden
  
  
• Aufträge können einen Eigentümer haben
  
  
• Für jeden Eigentümer können Event-Handler an die Ereignisse OnTasksStatus und OnTasksComplete gebunden werden
  
  
• Aufträge können gezielt abgebrochen werden, z.B nach dem Eigentümer (TMyPoolManager.CancelTasksByOwner)
  
  
• Jeder Auftrag verfügt über die Basis-Ereignisse: OnStart, OnCancel, OnDone und kann um beliebige weitere ergänzt werden
  
  
• Aufträge können priorisiert werden
  
  
• Der Manager unterstützt den Demand-Mode: D.h. er beendet sich selbst, wenn keine Aufträge anliegen und keine Arbeiter auf Vorrat gehalten werden müssen.
  
  
• Alle instanzierten Thread-Pools (Manager und Arbeiter) können mit einer einzelnen Anweisung (z.B. bei Programmende) sauber terminiert werden: TPoolManager.TerminateAllRunningPools
  
  
• Die Freigabe eines zuvor registrierten Eigentümer kann an alle Thread-Pools mittels TPoolManager.DispatchOwnerDestroyed übermittelt werden
  
  
• Dynamsiche Anpassung von gleichzeitigen und auf Vorrat zu haltenden Arbeitern an das Ziel-System mittels TMyPoolManager.ConcurrentWorkersCountPerCPU und TMyPoolManager.SpareWorkersCountPerCPU
  
  
• Last but not least: Kein Polling.
  Die Manager und Arbeiter lauschen mittels WaitFor(INFINITE) an ihren Hauptsignalen, dadurch wird kostbare Rechnerkapazität nicht sinnlos vergeudet.

Download

Damit ich das Archiv nicht bei jedem Update hier aktualisieren muss, verlinke ich am liebsten zur Projektseite bei SourceForge:

ThreadPool for Delphi (Download | Git-Repository)

Das Archiv enthält bereits zwei ausführliche Beispiele (auch in kompilierter Form), sodass man sowohl die Implementierung eines spezialisierten Thread-Pools nachvollziehen kann als auch dessen Verwendung.

Voraussetzung

Die Unit ist ab Delphi 2010 lauffähig.

Lizenz

Wie ich in der Einleitung geschrieben hatte, suchte ich nach einer Open-Source Lösung, die es nicht gab. Aus diesem Grunde stelle ich meine unter die MPL 1.1.

mfg

[Bernerbaer]

Ich habe mal versucht deine Beispiele zu kompilieren. Leider lässt sich ThreadPool unter meinem Delphi 2009 (alle aktuellen Updates eingespielt) nicht kompilieren.
Hier die Fehlermeldungen:

Code:

[DCC Fehler] ThreadPool.pas(183): E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet
[DCC Fehler] ThreadPool.pas(184): E2169 Felddefinition nicht erlaubt nach Methoden oder Eigenschaften
[DCC Warnung] ThreadPool.pas(184): W1010 Methode 'Destroy' verbirgt virtuelle Methode vom Basistyp 'TThread'
[DCC Fehler] ThreadPool.pas(188): E2254 Die überladene Prozedur 'Create' muss mit der Direktive 'overload' gekennzeichnet sein
[DCC Fehler] ThreadPool.pas(189): E2254 Die überladene Prozedur 'Destroy' muss mit der Direktive 'overload' gekennzeichnet sein
[DCC Fehler] ThreadPool.pas(191): E2252 Es gibt bereits eine Methode 'Destroy' mit identischen Parametern
[DCC Fehler] ThreadPool.pas(390): E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet
[DCC Warnung] ThreadPool.pas(390): W1010 Methode 'Destroy' verbirgt virtuelle Methode vom Basistyp 'TPoolThread'
[DCC Fehler] ThreadPool.pas(481): E2254 Die überladene Prozedur 'Destroy' muss mit der Direktive 'overload' gekennzeichnet sein
[DCC Fehler] ThreadPool.pas(483): E2252 Es gibt bereits eine Methode 'Destroy' mit identischen Parametern
[DCC Fehler] ThreadPool.pas(563): E2357 PROCEDURE, FUNCTION oder CONSTRUCTOR erwartet
[DCC Fehler] ThreadPool.pas(568): E2357 PROCEDURE, FUNCTION oder CONSTRUCTOR erwartet
[DCC Fehler] ThreadPool.pas(574): E2004 Bezeichner redefiniert: 'TPoolThread.Create'
[DCC Fehler] ThreadPool.pas(581): E2004 Bezeichner redefiniert: 'TPoolThread.Destroy'
[DCC Fehler] ThreadPool.pas(931): E2357 PROCEDURE, FUNCTION oder CONSTRUCTOR erwartet
[DCC Fehler] ThreadPool.pas(971): E2004 Bezeichner redefiniert: 'TPoolManager.Destroy'
[DCC Fehler] ThreadPool.pas(972): E2004 Bezeichner redefiniert: 'cc'
[DCC Fehler] ThreadPool.pas(183): E2065 Ungenügende Forward- oder External-Deklaration: 'TPoolThread.Create'
[DCC Fehler] ThreadPool.pas(184): E2065 Ungenügende Forward- oder External-Deklaration: 'TPoolThread.Destroy'
[DCC Fehler] ThreadPool.pas(390): E2065 Ungenügende Forward- oder External-Deklaration: 'TPoolManager.Destroy'
[DCC Fataler Fehler] PrimePoolForm.pas(6): F2063 Verwendete Unit '..\..\ThreadPool.pas' kann nicht compiliert werden

[WladiD]

Zitat:

Zitat von Bernerbaer (Beitrag 1068603)

Ich habe mal versucht deine Beispiele zu kompilieren. Leider lässt sich ThreadPool unter meinem Delphi 2009 (alle aktuellen Updates eingespielt) nicht kompilieren.
Hier die Fehlermeldungen:

Code:

[DCC Fehler] ThreadPool.pas(183): E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet
[DCC Fehler] ThreadPool.pas(184): E2169 Felddefinition nicht erlaubt nach Methoden oder Eigenschaften
[DCC Warnung] ThreadPool.pas(184): W1010 Methode 'Destroy' verbirgt virtuelle Methode vom Basistyp 'TThread'
....

Hmm, Mist , ich dachte das einzig "exotische" was ich in ThreadPool benutzt hätte, wären die Closures. Es wurde mit Delphi 2010 entwickelt und den Meldungen nach zu urteilen, unterstützt D2009 keine verschachtelten Typen, also sowas in der Art:

Delphi-Quellcode:

   
TPoolThread = class(TThread)
type // verschachtelte Typen deklaration
  TLockList = TObjectList<TMultiReadExclusiveWriteSynchronizer>;
  TCriticalSectionList = TObjectList<TCriticalSection>;
private
public
 ...
end;

Oder die Unterstützung der Generics (benutze massiv Generics.Collections.TObjectList) ist noch schlechter als in 2010.

Ich persönlich bin von 2007 gleich auf 2010 gesprungen und habe nie 2009 verwendet, aber dass es Closures (anonyme Methoden) beherrscht wusste ich. Tja, dann muss ich die Anforderungen vorerst einfach mal hochschrauben.

Danke für das Feedback.

[taveuni]

Zitat:

Zitat von WladiD (Beitrag 1068612)

Ich persönlich bin von 2007 gleich auf 2010 gesprungen und habe nie 2009 verwendet, aber dass es Closures (anonyme Methoden) beherrscht wusste ich. Tja, dann muss ich die Anforderungen vorerst einfach mal hochschrauben.
Danke für das Feedback.

Falls Du diesbezüglich was machst (2009 kompatibel), würdest Du auch in Betracht ziehen dies D2007 kompatibel (ohne Generics) zu machen?

[DeddyH]

Dann müsste man aber auch auf die anonymen Methoden verzichten, von daher habe ich persönlich wenig Hoffnung :(

[WladiD]

Zitat:

Zitat von taveuni (Beitrag 1068615)

Falls Du diesbezüglich was machst (2009 kompatibel), würdest Du auch in Betracht ziehen dies D2007 kompatibel (ohne Generics) zu machen?

Generics wären nicht das Problem, vielmehr ist es die fehlende Unterstützung von Closures, die mir eine Umsetzung für < D2009 scheinbar unmöglich machen (zumindest nach dem aktuellen Konzept). Sicherlich, wäre es irgendwie machbar, aber das würde meinen Zeitrahmen sprengen.

Wer einmal die Vorteile von Closures erkannt hat, kann nicht mehr ohne...

Sorry.

[Zwoetzen]

Wenn ich das richtig sehe, scheitert Delphi2009 am

Delphi-Quellcode:

class constructor Create;

bzw.

Delphi-Quellcode:

class destructor Destroy;

(die wohl für das Singleton-Pattern vorhanden sind?)

Ich habe mal testweise die Klassen-Konstruktoren und -Destruktoren auskommentiert, und sobald die vollständig gestrichen wurden, kompilierte Delphi2009 die Unit problemlos durch.
Meine Erfahrungen sagen auch, dass verschachtelte Typen (in D2009) kein Problem sein sollten, da ich die schon selbst mal verwendet hatte ;)


Ansonsten hört sich der ThreadPool schonmal sehr interessant an, wäre schön, wenn ich die nutzen könnte :)

[WladiD]

Zitat:

Zitat von Zwoetzen (Beitrag 1068630)

Wenn ich das richtig sehe, scheitert Delphi2009 am

Delphi-Quellcode:

class constructor Create;

bzw.

Delphi-Quellcode:

class destructor Destroy;

(die wohl für das Singleton-Pattern vorhanden sind?)

Ich habe mal testweise die Klassen-Konstruktoren und -Destruktoren auskommentiert, und sobald die vollständig gestrichen wurden, kompilierte Delphi2009 die Unit problemlos durch.
Meine Erfahrungen sagen auch, dass verschachtelte Typen (in D2009) kein Problem sein sollten, da ich die schon selbst mal verwendet hatte ;)


Ansonsten hört sich der ThreadPool schonmal sehr interessant an, wäre schön, wenn ich die nutzen könnte :)

Das ist doch was, womit ich etwas anfangen kann. Ich habe soeben die Hilfe durchforstet und finde kein Info, seit wann die die Klassenkonstruktoren/-destruktoren unterstützt werden. Werden Sie gänzlich nicht unterstützt, oder habe ich sie irgendwie falsch deklariert (z.B. muss im public/private)?

Ansonsten könnte man eine Compiler-Weiche einbauen und sich bei D2009 des initialization/finalization-Abschnitts bedienen.

[Zwoetzen]

Laut Google sollen die Klassen-Konstruktoren erst ab Delphi2010 unterstützt werden ;)


(Aus der Fehlermeldung

Zitat:

Zitat von DCC Fehler

E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet

würde ich auch schließen, dass D2009 allgemein kein

Delphi-Quellcode:

constructor

bzw.

Delphi-Quellcode:

destructor

nach einem

Delphi-Quellcode:

class

erwartet. Habe trotzdem mal die verschiedenen Sichtbarkeiten durchprobiert: Wie zu erwarten ohne Erfolg ;) )

[WladiD]

Zitat:

Zitat von Zwoetzen (Beitrag 1068640)

Laut Google sollen die Klassen-Konstruktoren erst ab Delphi2010 unterstützt werden ;)


(Aus der Fehlermeldung

Zitat:

Zitat von DCC Fehler

E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet

würde ich auch schließen, dass D2009 allgemein kein

Delphi-Quellcode:

constructor

bzw.

Delphi-Quellcode:

destructor

nach einem

Delphi-Quellcode:

class

erwartet. Habe trotzdem mal die verschiedenen Sichtbarkeiten durchprobiert: Wie zu erwarten ohne Erfolg ;) )

Alles klar Zwoetzen,

danke für die Information (war zu faul zum googeln :wink:), werde demnächst (bin grad an was anderem dran) die erwähnte Compiler-Weiche einbauen und mich hier wieder melden.

[WladiD]

Habe eine ungeteste Anpassung für Delphi 2009 eingebaut und ins Repository eingespielt:

ThreadPool (Revision 11)

Musste die bewährte "Compilers.inc" von Mike Lischke einbinden.

Kann das jemand testen und mir mitteilen, ob es sich damit jetzt compilieren lässt?

Dank im Voraus!

[Bernerbaer]

Danke für Deine Änderungen, aber:

ThreadPool lässt sich nun ohne Fehlermeldung kompilieren.

Die beiliegenden Demos stürzen jedoch ab, im folgenden die ersten Fehlermeldungen mit dem angezeigten Codeabschnitt:

Code:

function IsTaskValid(Task:TPoolTask):Boolean;
   begin
      Result:=Owner.Tasks.IndexOf(Task) >= 0;
   end;

->Erste Gelegenheit für Exception bei $76EDFBAE. Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 00475AF1 in Modul 'PrimePoolProject.exe'. Lesen von Adresse 00000000'. Prozess PrimePoolProject.exe (4432)

Code:

procedure TPoolManager.WorkerTerminated(TerminatedWorker:TPoolWorker);
begin
   BeginWriteWorkers;
   try
      Workers.Remove(TerminatedWorker);
   finally
      EndWriteWorkers;
      MainSignal.SetEvent;
   end;
end;

-> Erste Gelegenheit für Exception bei $76EDFBAE. Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 00475AF1 in Modul 'PrimePoolProject.exe'. Lesen von Adresse 00000000'. Prozess PrimePoolProject.exe (4432)

[WladiD]

Zitat:

Zitat von Bernerbaer (Beitrag 1068686)

Die beiliegenden Demos stürzen jedoch ab...

Kommt der Fehler sofort nach dem Programmstart oder erst wenn Sie auf den Button "Add tasks" klicken. Gibt es irgendeine Ausgabe im Memo, kommt die AV sporadisch oder immer an der selben Stelle. Oder treten die Fehler gar in meinen Kompilaten auf?

Fragen über Fragen. Hätte ich mir doch gleich denken können, dass man für keine "Plattform" programmiert, die man selbst nicht hat/testen kann. :cry:

[Bernerbaer]

Antworten

1. Der Fehler tritt erst auf wenn Add Task geklickt wird, der Fehler tritt erst am beim letzen (?) Durchlauf der Schleife for c:= 0 to Steps - 1 auf
2. Nein, im Memo werden keine Einträge angelegt
3. Die beiliegenden Kompilate der Demos laufen problemlos
4. Der Fehler tritt bei den vom mir kompilierten Demos immer auf.

[WladiD]

Zitat:

Zitat von Bernerbaer (Beitrag 1068692)

Antworten

1. Der Fehler tritt erst auf wenn Add Task geklickt wird, der Fehler tritt erst am beim letzen (?) Durchlauf der Schleife for c:= 0 to Steps - 1 auf
2. Nein, im Memo werden keine Einträge angelegt
3. Die beiliegenden Kompilate der Demos laufen problemlos
4. Der Fehler tritt bei den vom mir kompilierten Demos immer auf.

Generics/Closures waren neu in D2009 = alpha
Generics/Closures wurden in D2010 verbessert = beta
Generics/Closures wurden in DXE weiter verbessert = stable?

So oder so ähnlich wird es wohl sein. Genau da vermute ich den Fehler. Daher werde ich das bisher versuchte wieder droppen und nicht weiter probieren etliche Workarounds einzubauen, um mit D2009 kompatibel zu sein. Der ganze ThreadPool sollte ursprünglich komplett auf Generics basieren, welchen man nur die spezielle Task-Klasse übergibt, doch dort scheiterte ich, weil der Support der Generics noch nicht fehlerfrei ist, damit will ich sagen, dass ich schon mit 2010er meine Probleme hatte. So ist das mit neuen Möglichkeiten, doch irgendwann muss man sie nutzen um einen Nutzen zu erlangen.

Nichtsdestotrotz ist es Open Source, also wenn das jemand hinmoddeld, dass es funktioniert, dem ist ein Eintrag unter Credits/Copyrights sicher.

[WladiD]

Soeben habe ich die neue Version 1.0.1 veröffentlicht. (Links siehe 1. Beitrag)

Neben einigen Optimierungen enthält es jetzt die Unterstützung für priorisierbare Tasks. Ableitende Tasks können die Eigenschaften TPoolTask.Priority oder TPoolTask.PriorityRaw veröffentlichen und der entsprechende Manager muss die Eigenschaft TPoolManager.SortTasks auf TRUE setzen um die Sortierung zu aktivieren.

Wenn mehr Aufgaben hinzugefügt werden, als gleichzeitig abgearbeitet werden können, so kommen die Tasks mit der höheren Priorität eher dran.

Ach ja, als Voraussetzung bleibt: ab Delphi 2010 :shock:

[mquadrat]

Was vielleicht noch für den einen odere anderen nützlich sein könnte, wären Abhängigkeiten der Aufträge, so dass B erst nach A ausgeführt wird.

Prinzipiell ist die Sache super. Für mich zwar mangeld D2010/XE nicht nutzbar, aber es zeigt, dass die Community zumindest noch nich ganz kapituliert hat ;)

[WladiD]

Zitat:

Zitat von mquadrat (Beitrag 1068850)

Was vielleicht noch für den einen odere anderen nützlich sein könnte, wären Abhängigkeiten der Aufträge, so dass B erst nach A ausgeführt wird.

Das ist schon ohne weiteres Zutun möglich:

Delphi-Quellcode:

var
  Task:TMyTask;
begin
  Task:=TMyTask.Create(Owner);
  // Task mit Daten füllen
  Task.OnDone:=procedure(Sender:TObject)
  var
    DependTask:TMyTask;
  begin
    if TMyTask(Sender).State <> tsSuccess then
      Exit;
    DependTask:=TMyTask.Create(Owner);
    // DependTask mit Daten füllen

    TMyPoolManager.AddTask(DependTask);
  end;
  
  TMyPoolManager.AddTask(Task);
end;

Zitat:

Zitat von mquadrat (Beitrag 1068850)

... die Community zumindest noch nich ganz kapituliert hat"

Ich hoffe, dass diese Aussage sich nicht auf die These "Delphi ist tot" bezieht. Native (abwertend auch unmanaged) Code wird auch in 20 Jahren eine Rolle spielen. Beides muss sich nicht zwangsweise ausschließen. Hier ist eine ausführlichere Antwort: www.isdelphidead.com ? ;)

[mquadrat]

Auf die Idee mit dem Event-Handler war ich auch schon gekommen. Die Abhängigkeit mit in das Interface zu integrieren, würde weniger Glue-Code produzieren und man könnte Workflows fast 1:1 abbilden.

Natürlich wird Native-Code noch lange eine Rolle spielen. Aber IMHO werden es immer weniger Community-Projekte und 3rd-Party-Bibliotheken/Komponenten. Und schließlich waren die ganzen Projekte rund um Delphi lange ein Alleinstellungsmerkmal.

[WladiD]

Hallo alle zusammen,

heute habe ich die neue Version 1.0.3 des ThreadPool veröffentlicht (Download-Links wie gehabt im 1. Beitrag).

Die ThreadPool-Unit wurde massiv rationalisiert. Es werden jetzt weniger Locks benötigt und die ganze Unit konnte (trotz höherer Versionsnummer) etwas schrumpfen.

In der Version 1.0.2, die ich hier nicht vorstellte, gab es eine CodeSite-Integration, die mittels Compiler-Conditionals in der beiliegenden Compile.inc aktiviert werden kann. Es ist doch ziemlich schwierig soetwas mittels Breakpoints/OutputDebugString zu debuggen.

Desweiteren kam ein DUnit-Testprojekt hinzu, in dem —unter anderem– diverse Stress-Tests stattfinden, die vor jedem Release bestanden werden müssen. Es ist ebenfalls dem Archiv beigelegt.


Ich wünsche allen ein erfolgreiches neues Jahr!

P.S.: Ja, ich bin auf Delphi XE umgestiegen und bin sehr glücklich damit :-D. Da ich D2010 parallel betreibe, ist (und hoffentlich bleibt) der ThreadPool weiterhin damit kompatibel.

[WladiD]

Ein Hallo an alle DP-Mitglieder,

muss seit gestern wieder den ThreadPool erweitern und habe einige heikle Änderungen durchführen müssen. Soweit sieht es ganz gut aus, die DUnit-Tests laufen problemlos, auf meinem Core-i7 920 und in Virtual-PC (Single-Core), durch. Doch was heisst das schon...ich brauche noch ein paar Tests von anderen Systemen.

Wer ist von Euch so nett und lässt den angehängten (kompilierten) Test auf seinem Rechner laufen?

Wenn ihr die Exe startet, reicht ein Klick auf den grünen Play-Button (oder Enter-Taste), um einen Test-Durchlauf zu starten. Ein kompletter Durchlauf dauert, je nach System, ca. 1-3 Minuten. Jeder bestandene Teil-Test wird grün gekennzeichnet. Wichtig ist, dass es komplett grün durchläuft (wie im angehängten Screenshot).

Schön wäre es auch, wenn Ihr den gesamten Test mehrmals wiederholen könntet. Drückt dazu jeweils auf Enter, wenn es fertig ist.

Natürlich brauche ich dann Feedback (am besten mit Screenshot), wenn es nicht durchläuft oder gar Exceptions geworfen wurden. Aber über ein einfaches "Läuft komplett durch!", würde ich mich auch freuen. ;-)

mfg

P.S.: Die aktuellen Codes sind im Git-Repository bei SF abrufbar (falls es jemand selbst kompilieren möchte).

[Neutral General]

Hallo,

:arrow: "Läuft komplett durch!" ;)

Intel Core 2 Duo, 2,93GHz
2GB RAM
Windows Vista 32-Bit

Gruß
Neutral General

[WladiD]

Zitat:

Zitat von Neutral General (Beitrag 1093635)

Hallo,

:arrow: "Läuft komplett durch!" ;)

Intel Core 2 Duo, 2,93GHz
2GB RAM
Windows Vista 32-Bit

Gruß
Neutral General

Super, Danke!

[wicht]

Hi,

drei mal laufen lassen, keine Probleme :P

[WladiD]

Zitat:

Zitat von wicht (Beitrag 1093642)

Hi,

drei mal laufen lassen, keine Probleme :P

Auch dir ein Dankeschön!

Da ich parallel schon zig Tests durchgeführt habe, sehe ich jetzt einfach mal die Änderungen als "stabil" an.

[DeddyH]

Ich denke, das ist berechtigt, selbst auf meinem "vermurkten" Laptop mit Vista 32 Bit treten keine Fehler auf.

[ConstantGardener]

...3 Starts, drei mal ohne Fehler (Win 7 64 Bit, Core X5)

[Neutral General]

Hi,

Weils so viel Spaß gemacht hat, nochmal auf meinem Rechner zuhause, wieder ohne Probleme ;)

Intel Core i5 - 2,66GHz
4GB RAM
Windows 7 Professional 64 Bit

[mirage228]

Moin moin,

Core i7-860 2.8 GHz
8 GB RAM
Windows 7 Professional x64

läuft alles 1A durch ;)

[WladiD]

Ein gebündeltes Dankeschön an alle Tester!

Ihr könnt euch nicht vorstellen, wie sehr mich diese Ergebnisse beruhigen und motivieren. Es ist gar nicht so einfach einen Thread-Pool ohne eine (Windows-)Message-Queue, sondern nur mit Delphi-Bordmitteln umzusetzen. Ich bin nämlich optimistisch in den kommenden Jahren diesen auf Mac und Linux laufen sehen zu können. :twisted:

[Hunni]

Hallo,

auch auf meinem Hightech Rechner (Pentium 4 3GHz HT ) mit Windows 7pro lief der Test ohne Probleme durch.
Hat halt nur etwas gedauert :-)


Torsten

[WladiD]

Heute habe ich die neue Version 1.0.9 veröffentlicht.

Was ich hier ehemals Vorstellte, hat sich (mal wieder) grundlegend geändert, aus diesem Grund habe ich den 1. Beitrag komplett überarbeitet (siehe oben).

Diese Unit wird übrigens produktiv in Lauge eingesetzt.

Dort werden 2 spezielle Thread-Pools verwendet. Einer für sämtliche HTTP-Anfragen und ein Bild-Skalierungs-Thread-Pool :lol:

[freimatz]

Gibt es etwas Neues? Läuft das auch unter XE2, XE3 oder XE4?

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1214336)

Gibt es etwas Neues? Läuft das auch unter XE2, XE3 oder XE4?

Wenn du es anpasst sicherlich: http://sourceforge.net/u/wladid/thre...i/master/tree/
Ich denke mit Anpassung der Compilers.inc sollte es vermutlich in XE2...X4 funktionieren.

[freimatz]

Also es gibt nichts Neues. Hintergrund der Frage ist, dass bei uns eine Evaluierung zum Einsatz eines Threadpools stattfindet. Eine Bibliothek, die laufend gepfegt wird, hat da Pluspunkte. :)

[WladiD]

Ich weiß nicht mehr wieviele Male ich mir fest vorgenommen habe mich wieder da ran zu setzen... :roll: Auch AnyiQuack und Lauge will ich irgendwann mal wieder auf Vordermann bringen. Und die Projektseiten müssten auch mal gepflegt werden.

Nach der Arbeit hab ich einfach keine Zeit/Lust mehr oder ich werde einfach zu alt. :?

[Delphi-Laie]

Zitat:

Zitat von WladiD (Beitrag 1214536)

Ich weiß nicht mehr wieviele Male ich mir fest vorgenommen habe mich wieder da ran zu setzen... :roll:

Was schwebt(e?) Dir denn vor, Waldemar? Ist der Threadpool mit immerhin der Version 1.09 nicht ausgereift, oder gibt es noch grundsätzliche fehlende Essentialien, die Dir zu ergänzen vorschweben? Oder geht es doch nur um Hinzufügung der vordefinierte Symbole für RAD-Studio XEx?