ThreadPool API

[Kraisel]

Hallo,

wer weiß, wo ich für XE5 die Windows Threadpool API finde, oder wie ich die API-Funktionen selber einbinden kann. Es scheint keine Unit dafür zu geben? Oder habe ich da etwas übersehen?

Vielen Dank.

[Kraisel]

Hallo,

habe ich unklar gefragt, oder gibt es tatsächlich niemanden, der mit der Windows ThreadPool-API arbeitet?

Vielen Dank.

[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:

Zitat von jensw_2000 (Beitrag 1248623)

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:

Zitat von sahimba (Beitrag 1248624)

Zitat:

Zitat von jensw_2000 (Beitrag 1248623)

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:

Zitat von jensw_2000 (Beitrag 1248626)

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.

[TiGü]

Also entweder selber übersetzen, wie Günther auch schon vorgeschlagen hat.
Ist ja eigentlich recht überschaubar.
Hier die Arbeit von fünf Minuten:

Delphi-Quellcode:

unit ThreadPool;

interface

uses
  Winapi.Windows;

type

TP_POOL = record

end;
PTP_POOL = ^TP_POOL;

function CreateThreadpool(reserved : Pointer = nil) : PTP_POOL; stdcall;

function SetThreadpoolThreadMinimum(ptpp: PTP_POOL; cthrdMin : DWORD) : BOOL; stdcall;

procedure SetThreadpoolThreadMaximum(ptpp: PTP_POOL; cthrdMost : DWORD); stdcall;

procedure CloseThreadpool(ptpp : PTP_POOL); stdcall;

function CreateThreadpool; external kernel32 name 'CreateThreadpool';
function SetThreadpoolThreadMinimum; external kernel32 name 'SetThreadpoolThreadMinimum';
procedure SetThreadpoolThreadMaximum; external kernel32 name 'SetThreadpoolThreadMaximum';
procedure CloseThreadpool; external kernel32 name 'CloseThreadpool';

implementation
end.

Delphi-Quellcode:

implementation

uses
  ThreadPool;

{$R *.dfm}

procedure TForm2.Button1Click(Sender: TObject);
var
  MyThreadPool : PTP_POOL;
begin
  MyThreadPool := CreateThreadpool;
  if SetThreadpoolThreadMinimum(MyThreadPool, 1) then
  begin
    SetThreadpoolThreadMaximum(MyThreadPool, 100);
  end;
  CloseThreadpool(MyThreadPool);
end;

Auch ein möglicherweise effektiverer Weg wäre das erstellen einer C++-DLL, die die Funktionalität mithilfe eines COM-Interfaces für Delphi bereitstellt.
Der richtige Code kann direkt in C++ geschrieben werden, ohne jeden Mist an struct und Pointer (oder Pointer auf Pointer) zu übersetzen.
Das Interface-Objekt selber hätte dann nur die allernötigsten Methoden zum Verwalten des ThreadPools.

Delphi-Quellcode:

IThreadPool = interface(IUnknown)
  procedure SetMinimum(NumberOfThreads : DWORD); stdcall;
  procedure SetMaximum(NumberOfThreads : DWORD); stdcall;
end;

[Kraisel]

Vielen Dank,

auf die Idee wäre ich gar nicht gekommen, das Interface einfach selber zu schreiben. Eigentlich logisch, aber von mir bisher konsquent ignoriert. Wieder eine neue gute Erfahrung. Danke.

Aber wir komme ich nun an die ganzen Übergabe-Recordtypen und deren Bedeutung der Threadpool-Methoden heran? Hierzu habe ich keine Hinweise oder Beispiele bei Microsoft gefunden.

Liebe Grüße aus Bochum.

[TiGü]

Was hast du denn konkret vor?
Beschreibe doch mal dein Vorhaben!

Ich würde versuchen so wenig wie möglich Datentypen der Threadpool-API zu übersetzen, um sie in Delphi zu verwenden.
Wenn überhaupt, dann wieder als Interface-Objekte.

Ich habe mit dieser konkreten API nicht gearbeitet, aber anscheinend ist das Grundprinzip einfach Callbacks und Daten als typlose Pointer zu übergeben.
Korrigiere mich, wenn ich falsch liege.

Wenn du mal hier schaust:
http://archive.msdn.microsoft.com/win32threadpool

Da hat sich jemand schon die Mühe gemacht, diese API in Objekte zu gießen.
Schau doch mal, was für dich sinnvoll verwendbar ist.

Was du dann brauchst, abstrahiert du als Interface, schreibst eine Factory-Funktion dafür und steckst diese in deine C++-DLL.
Das Interface übersetzt du dann in Delphi und benutzt es einfach.

Wenn du zu diesem Schritt Fragen hast, schaue dir mal in Ruhe folgenden Artikel an:
http://rvelthuis.de/articles/articles-cppobjs.html

Er basiert zwar auf (Borland) C++Builder, aber das Vorgehen ist in Visual C++ ähnlich wenn man bspw. das WRL::ComPtr-Template nutzt.

[michaelthuma]

Probiere mal in purem C und schau ob es geht. Ganz sicher bin ich mir nicht, ob ich das Thema verfehle.

Wohl aber gab es unter Win7 teils noch Troubles. Unter XP und Vista glaube ich gar nicht verfügbar bis hin zu ungeklärten Fehlern die von Fall zu Fall auftraten und sich keiner wirklich konnte erklären. Thema rund um die Worker Threads am Desktop.

Auf der Serverseite wurde der Nutzen von einigen Kommentatoren als durchaus bescheiden eingestuft. Verblieb dann der Einsatz am Desktop und ...

Meinerseits war es allein ein Intermezzo.

Zitat:

Zitat von Kraisel (Beitrag 1248605)

Hallo,

habe ich unklar gefragt, oder gibt es tatsächlich niemanden, der mit der Windows ThreadPool-API arbeitet?

Vielen Dank.