QueueUserWorkItem wie sieht es in Delphi aus?

[Luckie]

Die Funktion ist so deklariert:

Code:

BOOL QueueUserWorkItem(
  LPTHREAD_START_ROUTINE Function,
  PVOID Context,
  ULONG Flags
);

Mit welchem Datentyp übersetzt man den ersten Parameter in Delphi?

Im PSDK steht noch dazu:

Zitat:

[in] Pointer to the application-defined callback function of type LPTHREAD_START_ROUTINE to be executed by the thread in the thread pool. This value represents the starting address of the thread. This callback function must not call the TerminateThread function.
For more information, see ThreadProc.

Google war diesmal irgendwie nicht sehr hilfreich. :-?

[Luckie]

OK, ich habs jetzt. Mein Beispielprogramm sieht jetzt so aus:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
    i: Cardinal;
  public
    { Public declarations }
  end;

type
  TThreadParams = record
    ThreadID: Cardinal;
  end;
  PThreadParams = ^TThreadParams;

var
  Form1                  : TForm1;

function QueueUserWorkItem(LPTHREAD_START_ROUTINE: Pointer; Context: Pointer; Flags: DWORD): DWORD; stdcall; external
  'kernel32.dll';

const
  WT_EXECUTEDEFAULT      = $00000000;
  WT_EXECUTEINIOTHREAD   = $00000001;
  WT_EXECUTEINUITHREAD   = $00000002;
  WT_EXECUTEINWAITTHREAD = $00000004;
  WT_EXECUTEONLYONCE     = $00000008;
  WT_EXECUTEINTIMERTHREAD = $00000020;
  WT_EXECUTELONGFUNCTION = $00000010;
  WT_EXECUTEINPERSISTENTIOTHREAD = $00000040;
  WT_EXECUTEINPERSISTENTTHREAD = $00000080;
  WT_TRANSFER_IMPERSONATION = $00000100;

implementation

{$R *.dfm}

function Thread(p: Pointer): Integer;
var
  hWnd: THandle;
  ThreadID: Cardinal;
begin
  ThreadID := PThreadParams(p)^.ThreadID;
  Messagebox(0, PChar(IntToStr(ThreadID)), '', 0);
  Dispose(p);
  result := 0;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  ThreadParams: PThreadParams;
begin
  New(ThreadParams);
  ThreadParams.ThreadID := i;
  if QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTEONLYONCE) = 0 then
    ShowMessage(SysErrorMessage(GetLastError));
  Inc(i);
end;

Allerdings habe ich da noch ein Verständnisproblem oder so:
Ich klicke einmal, ich bomme die Messagebox null, ich klicke ein zweites mal, ich bekomme die Messagebox eins, ich klicke ein drittes mal, es passiert nichts, ich klicke ein viertes mal, es passiert nichts, ich klicke ein fünftes mal, ich bekomme die Messagebox drei. Entsprechd wird auch nur die Anzahl der Threads im Taskmanager erhöht. Aber sollte es nicht so sein, dass bei jedem Aufruf von QueueUserWorkItem ein Thread erzeugt wird? Oder wie soll das funktionieren?

[Union]

Zitat:

Zitat von Luckie

Die Funktion ist so deklariert:

Code:

BOOL QueueUserWorkItem(
  LPTHREAD_START_ROUTINE Function,
  PVOID Context,
  ULONG Flags
);

Mit welchem Datentyp übersetzt man den ersten Parameter in Delphi?

Im PSDK steht noch dazu:

Zitat:

[in] Pointer to the application-defined callback function of type LPTHREAD_START_ROUTINE to be executed by the thread in the thread pool. This value represents the starting address of the thread. This callback function must not call the TerminateThread function.
For more information, see ThreadProc.

Google war diesmal irgendwie nicht sehr hilfreich. :-?

Wie wärs denn mit @MyThreadStartFunction ? Aufbau dieser Funktion wie ThreadProc.

[Luckie]

Ein einfacher Pointer tut es auch, wie man sieht. ;) Aber ich hätte jetzt gerne noch Aufklärung über das Funktionsprinzip. :gruebel:

[Basilikum]

die Calling-Convention deiner Thread-Funktion stimmt übrigens nicht; richtig wäre StdCall:

Delphi-Quellcode:

function Thread(p: Pointer): Integer; StdCall;

[Union]

WT_EXECUTEONLYONCE steht bei MS nicht in der Liste der für QueueUserWorkItem gültigen Flags...

[Luckie]

@Basilikum: Das ändert nichts am Verhalten.
@Union: Ist aber in WinNT.h deklariert.

Aha, so gehts:

Delphi-Quellcode:

function Thread(p: Pointer): Integer; stdcall;
var
  ThreadID: Cardinal;
begin
  ThreadID := PThreadParams(p)^.ThreadID;
  Messagebox(0, PChar(IntToStr(ThreadID)), '', 0);
  Dispose(p);
  result := 0;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  ThreadParams: PThreadParams;
begin
  New(ThreadParams);
  ThreadParams.ThreadID := i;
  if QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTELONGFUNCTION) = 0 then
    ShowMessage(SysErrorMessage(GetLastError));
  Inc(i);
end;

stdcall und WT_EXECUTELONGFUNCTION zusammen erzeugen jedes mal einen neuen Thread.

Aber hilft mir das bei folgendem Szenario: Ich habe einen Server zum dem verbinden sich Clients. Es sollen maximal fünf Client-Threads laufen. das heißt, wenn fünf Thread schon existieren, soll es keinen neuen mehr geben, sondern der sechste Cliuent soll sich erst verbinden können, wenn einer der ersten fünf Clients sich wieder verabschiedet hat. Wenn sich das mit QueueUserWorkItem machen läßt, wie löst man das problem am besten?

Laut PSDK soll das ja möglcih sein:

Zitat:

There are many applications that create threads that spend a great deal of time in the sleeping state waiting for an event to occur. Other threads may enter a sleeping state only to be awakened periodically to poll for a change or update status information. Thread pooling enables you to use threads more efficiently by providing your application with a pool of worker threads that are managed by the system. At least one thread monitors the status of all wait operations queued to the thread pool. When a wait operation has completed, a worker thread from the thread pool executes the corresponding callback function.

Ich erzeuge als gleich fünf Threads und wenn ein Client kommt wird ein Thread aus dem ThreadPool genommen, der ihn bedient. Fällt jemanden dazu eine kleine Demo Anwendung ein?

[Flocke]

Zitat:

Zitat von Luckie

@Basilikum: Das ändert nichts am Verhalten.

Das stimmt natürlich nicht. Bei der Standardaufrufkonvention "register" wird der erste Parameter in EAX übergeben, bei "stdcall" auf dem Stack. Du hast also einfach "Glück" wenn's trotzdem funktioniert.

[Luckie]

Ich weiß, ich spame, aber ich habe es gerade gefunden:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  ThreadParams: PThreadParams;
begin
  New(ThreadParams);
  ThreadParams.ThreadID := i;
  if QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTEDEFAULT) = 0 then
    ShowMessage(SysErrorMessage(GetLastError));
  Inc(i);
end;

Übergibt man als Flag: WT_EXECUTEDEFAULT ergibt sich obige Situation: Dass Messagebox zwei nicht erscheint. Schließe ich eine alte Messagebox, erscheint Mesaagebox zwei, ohne dass ich noch mal auf die Schaltfläche geklickt habe. Tut also alles, wie es soll. ;)

Fällt jemanden jetzt dazu eine schöne Demoanwendung ein?

[Union]

Zitat:

Zitat von Luckie

Aber hilft mir das bei folgendem Szenario: Ich habe einen Server zum dem verbinden sich Clients. Es sollen maximal fünf Client-Threads laufen. das heißt, wenn fünf Thread schon existieren, soll es keinen neuen mehr geben, sondern der sechste Cliuent soll sich erst verbinden können, wenn einer der ersten fünf Clients sich wieder verabschiedet hat. Wenn sich das mit QueueUserWorkItem machen läßt, wie löst man das problem am besten?

Maximale Anzahl Threads setzt Du, indem Du auf die Flags MaxThreads * $10000 addierst:

Zitat:

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.


#define WT_SET_MAX_THREADPOOL_THREADS(Flags,Limit) ((Flags)|=(Limit)<<16)

Alternativ kannst Du auch mit Mutexen arbeiten oder einen Zähler im steuernden Prozess verwenden.

[Luckie]

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

Sollte das dann so aussehen?

Delphi-Quellcode:

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:

Delphi-Quellcode:

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:

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.