QueueUserWorkItem wie sieht es in Delphi aus?

[Luckie]

Die erste Lösung klingt doch schon mal gut. Besten Dank.

Sollte das dann so aussehen?
QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTELONGFUNCTION or 2 * $10000) Weil das funktioniert irgendwie nicht:

Delphi-Quellcode:

function Thread(p: Pointer): Integer; stdcall;
var
  LBIndex                : Cardinal;
  Cnt                    : Cardinal;
begin
  LBIndex := PThreadParams(p)^.LBIndex;
  for cnt := 0 to 99 do
  begin
    TListbox(Form1.FindComponent('Listbox' + IntToStr(LBIndex))).Items.Add(IntToStr(cnt));
    sleep(50);
  end;
  result := 0;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  ThreadParams           : PThreadParams;
  i                      : Integer;
begin
  New(ThreadParams);
  for i := 1 to 6 do
  begin
    sleep(10);
    ThreadParams.LBIndex := i;
    if QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTELONGFUNCTION or 2 * $10000) = 0 then
      ShowMessage(SysErrorMessage(GetLastError));
  end;
end;

Es werden doch alle sech Listboxen gleichzeitig ausgefüllt. Und ohne das Sleep(10) kommt er sogar durcheinander und füllt die letzte mehrmals aus.

[Luckie]

Ich habe mal eine bessere Demoanwendung geschrieben:

Sie besteht aus einem Empfänger und einem Sender. Der Sender schickt eine Anforderung an den Empfänger, der daraufhin eine Listbox füllen soll. Auf dem Empfänger-Formular befinden sich sechs Listboxen, der Sender gibt dem Empfänger jeweils mit, welche Listbox gefüllt werden soll. Der Empfänger erzeugt dann entweder, je nach Auslastung, einen neuen Thread im Thread-Pool oder wartet bis ein Thread fertig ist und die Anforderung übernehmen kann.

Klicke ich zum Beispiel vier mal auf die Schaltfläche des Senders werden erst zwei Listboxen gefüllt und die verbleibenden zwei erst, wenn die Threads der ersten zwei Listboxen fertig sind. Dabei sollte man immer mal die Statusleiste des Empfängers beobachten, die die Anzahl der Threads anzeigt und gucken, wie die Listboxen gefüllt werden. Und wartet man bis die ersten Threads fertig sind und sendet dann eine weitere Anforderung, wird man sehen, dass keine weiteren Threads im Thread-Pool erzeugt werden.

Dann sollte man mal den Flag WT_EXECUTEDEFAULT durch den Flag WT_EXECUTELONGFUNCTION austauschen und wieder das Verhalten des Empfängers beobachten. WT_EXECUTELONGFUNCTION teilt dem System mit, dass der aufgerufene Thread etwas länger braucht bis er zurückkehrt, was das Erstellen von neuen Threads im Thread-Pool durch das System beeinflusst. Es neigt dann nämlich eher dazu einen neuen Thread zu starten.

Die Anzahl der Threads soll man so:
QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTEDEFAULT or 5 + $10000) beeinflussen können. In diesem Fall sollten jetzt nur maximal fünf Threads gestartet werden. Bei mir hat das aber noch nicht so ganz geklappt, glaube ich.

Demo im Anhang.

[NicoDE]

Zitat von MSDN:

By default, the thread pool has a maximum of 512 threads per process. To raise the queue limit, use the WT_SET_MAX_THREADPOOL_THREAD macro defined in Winnt.h.

Da steht nicht explizit, dass niedrigere Grenzen eingehalten werden (bei Thread-Pools gelten die Grenzen AFAIK als 'Empfehlung').

[Luckie]

Ah, OK, also kann man es nicht so beeinflussen, wie ich dachte, dass man es könnte. Kann man eigentlich die Threads wieder irgendwie aus dem Thread-Pool löschen? Oder hängen die jetzt bis zum Prozessende da drinn? Verbrauchen die eigentlich Ressourcen im Thread-Pool?

[Robert Marquardt]

Es empfiehlt sich die Jedi-Apilib zu verwenden (JwaWinBase.pas). http://jedi-apilib.sf.net
Dort ist die Funktion mit einem korrekten Typen fuer den Callbackparameter deklariert.

Wer den Zugriff auf das CVS nicht scheut der bekommt jetzt auch noch ein JwaWindows.pas das die einzelnen Teilfiles per Include vereinigt.

[Luckie]

Danke für den Hinweis, das beantwortet aber leider nicht meine abschließende Frage.