ThreadPool API

[himitsu]

Noch nie was von mitbekommen.

Den einzigen ThreadPool, den ich im Delphi kenn, ist im Indy versteckt.

Ein paar Pools gibt es noch im DBX (DataSnap) und in den DB-Zugriffskomponenten, wo alte Threads abgelegt werden, um schnell Einen zu haben, wenn man wieder Einen braucht,
was aber vermutlich auch die Arbeitsweise der TidThreadPoolIrgendwas-Komponente ist, über die ich mal zufällig vorbeigelaufen bin, auf der Suche nach irgendwas Anderem.



'nen Link ins MSDN hattest du nicht gehabt, als ich gestern den Beitrag las.
Sonst hätte ich mal schnell nachgesehn, ob ich irgendwo was mit der API rumliegen hab, bzw. irgendwo etwas entdecke.

[Der schöne Günther]

Ohne es genau zu wissen, das von Indy ist glaube ich was von denen selbstgebasteltes.

Das war schon klar gefragt, keine Bange. Das Pooling das du meinst gibt es erst seit einem halben Jahrzehnt, ist in Delphi bislang genauso wenig angekommen wie die Pointer-API.

Ich habe spontan auch nichts gefunden, aber aufwändig wäre es ja jetzt auch nicht den Header selbst machen. Du brauchst ja im Endeffekt nur die ganzen in der Doku aufgelisteten Funktionaufrufe in einer .pas zu sammeln. Zusätzlich noch die ganzen verwendeten Strukturen auf Delphi-Records abbilden.

(Gibt es da nicht vielleicht einen Automatismus? Wie haben die ganzen Borland/Embarcadero-Leute das eigentlich gemacht? Doch sicher nicht alles von Hand?)

[jensw_2000]

Der Threadpool den Du vermutlich aus .Net kennst habe ich den Delphi noch nie entdeckt. Dabei habe ich in meinen Webservices (glaube ich) recht intensiv mit Multithreading in Delphi gearbeitet. Also ich behaupte es gibt keine Delphi Implementation für das Threadpool/Task Konstrukt und das "Task driven Multithreading". Ich bin mir noch nicht einmal sicher, ob das nicht eine reine .NET API ist. Muss mir unbedingt nochmal den Video2Brain Streifen zu Gemüte führen....

[sahimba]

Zitat von jensw_2000:

Also ich behaupte es gibt keine Delphi Implementation für das Threadpool/Task Konstrukt und das "Task driven Multithreading".

Schaut Euch doch einmal Omnithreading an.
http://www.thedelphigeek.com/

Cheers,
S.

[jensw_2000]

Zitat von sahimba:

Zitat von jensw_2000:

Also ich behaupte es gibt keine Delphi Implementation für das Threadpool/Task Konstrukt und das "Task driven Multithreading".

Schaut Euch doch einmal Omnithreading an.
http://www.thedelphigeek.com/

Cheers,
S.

Ja, Omnithreading ist super. Aber ich glaube Kraisel meine eher eine Delphi API für das hier. Als reine Delphi/TThread basierte Lösung fand ich Alzaimar's Workerthread Pool Implementation immer sehr brauchbar. Lief traumhaft, war einfach und übersichtlich und kam ohne Drittanbieterkomponenten aus.

[TiGü]

Zitat von jensw_2000:

Aber ich glaube Kraisel meine eher eine Delphi API für das hier.

Wohl eher die native C++ Schnittstelle zur API:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Vertiefende Artikel aus dem MSDN Magzine:
http://msdn.microsoft.com/en-us/magazine/hh394144.aspx
http://msdn.microsoft.com/en-us/magazine/cc163327.aspx

[Kraisel]

Hallo,

ja, es geht um die API, die TiGü auch aufgelistet hat.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Der ThreadPool ist genial, wenn man mit vielen Timern oder auch WorkMethoden arbeitet, die aber jeweils nur geringe Laufzeiten benötigen. Es entfallen dann die sehr langsamen Thread-Initialisierungen und Deinitialiesungen, und es können pro Pool bis zu 500 Timer, Threads bzw. Worker created werden (und zwar fast ohne CPU-Zeit).

Ich habe zwar einen eigenen ThreadPool, der auch seit vielen Jahren in industriellen Anlagen (365x24) eingebaut ist und super funktioniert, aber der ThreadPool von Windows bietet "native" Mechanismen und Methoden, die man selber nicht schreiben kann, da sie eng mit dem Scheduler von Windows zusammenarbeiten.

OmniThread ist für mich keine Alternative, da ich für Zentralwerkzeuge auch grundsätzlich nur systemeigene Module einsetze. Wenn es langlebig werden soll, muss man leider vieles selber bauen.