Zuweisen unterschiedlicher Aufgabe für Threads

[endeffects]

hallo =),

ich arbeite zur zeit noch immer an einem programm das mit hilfe
von threads mehrere abläufe gleichzeitig erledigt.

diese threads arbeiten zur zeit leider immer nur ein und die selbe
aufgabe ab, dies könnte ich natürlich beim erzeugen der threads verhinden,
allerdings wäre dann die anzahl der aufgaben auf die anzahl der threads begrenzt.

ich möchte daher ein globales array erzeugen und einen zeiger
der immer auf das nächste element im array verweist,
damit die threads dieses array bis zum ende abarbeiten

nun hab ich mir folgenden code zusammen gebastelt,
der zwar keinen fehler erzeugt aber den zeiger auf das array
nicht erhöht

ersteinmal die unit für die threads:

Delphi-Quellcode:

unit Unit2;

interface

uses
  Classes, SysUtils, IdComponent, IdTCPConnection, IdTCPClient;

type
  TMyThreads = class(TThread)
  private
    procedure UpDateCounter;
    procedure LunchThread;
    ...
  public
    FCounter: Integer;
  ...

implementation

uses
  Unit1;

procedure TMyThreads.Execute;
begin
  FCounter:= FCounter+1;
  Synchronize(UpdateCounter);
  LunchThread;
end;
...

procedure TMyThreads.UpDateCounter;
begin
  MainForm.ArrayPointer := FCounter;
end;

und nun die unit 1

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Controls, Forms, StdCtrls, ComCtrls,
  Unit2, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, IniFiles;

type
  TMainForm = class(TForm)
  ...
  public
    { Public-Deklarationen }
    ArrayPointer: Integer;
    procedure UpdateCounter(Counter: integer);
  ...

implementation

procedure TMainForm.UpdateCounter(Counter: integer);
begin
  ArrayPointer := Counter;
end;

hat jemand vielleicht ein vorschlag wie man soetwas besser lösen kann
bzw findet den fehler?

mfg

[bttb930]

finde deine beschreibung etwas schwammig, glaube aber dass FCounter keine TThread-Variable sein sollte, sondern eine Unit-Variable. Dann sollte allerdings auch die Addition synchronisiert werden.

Lies mal das Buch "Delphi in a nutshell" vom O'Reilly-Verlag, dort wird Thread-Programmierung beschrieben.

[endeffects]

Zitat:

finde deine beschreibung etwas schwammig

hmm also die unit1 erzeugt x threads die dann mit werten
aus einem array gefüttert werden sollen, jeder thread
soll dann jeweils einen wert aus dem array nutzen um
seine aufgabe zu erfüllen, das ganze dann so lange bis alle
elemente im array abgearbeitet wurden, d.h. bei 50 threads
und 150 werten im array muss jeder thread 3 werte abarbeiten

[scp]

Wenn du FCounter dort lassen willst, wo er jetzt ist musst du ihn auf jeden Fall beim erstellen eines Threads initialisieren, zum Beispeil durch übergabe des aktuellen ArrayPointer als Parameter im Create.

[endeffects]

aber im normalfall ist doch jede variable mit dem wert 0 initialisiert,
wenn ich mich jetzt richtig erinner

[BorisN]

In deinem Fall fängt jeder Thread bei Index 0 an. Solange also der Sync nicht erfolgt arbeiten alle Threads den gleichen Eintrag ab. Besser wäre hier eine Art Queue (Qarteschlange) in Form von TThreadList, in die Du Aufgaben Reinstellst, die jeder Thread abholen kann. Das Reinstellen und Abholen muss natürlich synchronisiert werden (TThreadList.LockList).

In etwa:

Code:

Unit MyThread;

Var
  MainList: TThreadList;

procedure Thread.Execute;
Var
  List: TList;
  Entry: TObject; // oder was auch immer du in der Liste hast
begin
  List := MainList.LockList;
  Entry := List.Items[0];
  List.Delete(0);
  MainList.UnLockList;

  // Verarbeiten:
  If Entry.Aufgabe = eaLesen then
  begin
    // ...
  end;

  Entry.Free;
end;

procedure Button1Click(Sender....);
Var
  List: TList;
begin
  // Eintrag hinzufügen Bsp.
  List := MainList.LockList;
  List.Add(MyObject);
  MainList.UnLockList;
end;

Ist nur eine Grobe Ablaufbeschreibung.

[choose]

Hallo endeffects,

wenn Du jedem Thread eine feste Anzahl an Aufgaben zuordnest, könnte die Aufgabenverteilung suboptimal verlaufen (zB falls die Aufgaben des ersten zweier Threads schnell zu verarbeiten wären und die des zweitens recht zeitaufwändig sind). Darüber hinaus bist Du in der Wahl der Anzahl der Threads unflexibel, was im Allgemeinen ein Problem bei begrenzten Ressourcen (zB endliche Anzahl von Netzwerkverbindungen oder Datenbanksessions) darstellen kann.

Sofern ich Dein Problem richtig verstehe, handelt es sich um einen Klassiker des Producer-/Consumer-Problems mit mehreren Consumern (und einem "nie aktiven" Producer). Du kannst es also generell Lösen, indem Du einen Pool (genauer eine Queue) von "Aufgaben" erzeugst, der von einem Producer (hier: Einmalig Dein Programm beim erzeugen der Arraywerte) gefüllt und von den Comsumern variabler Anzahl aus einem Threadpool abgearbeitet werden. Mithilfe von Synchronisationsobjekten (zB Events) kannst Du die Consumer "einfrieren" bis neue Aufgaben anstehen (selbstverständlich ist die Queue selbst ebenfalls gegen zeitgleichen Zugriff zu sperren).

Suche im Netz nach gängigen Lösungsmustern für dieses Problem.

[endeffects]

hallo,
ersteinmal danke für eure anregungen,
mal schaun ob ich dazu noch was finde

[Luckie]

Wenn es nur ab 2000 laufen soll kann Windows diesen Thread Pool für dich verwalten. Stichwort für das PSDK wäre QueueUserWorkItem. Weiter kann ich dir auch nicht helfen im Moment, da ich selber mir gerade dieses Thema mit den Thread-Pools erarbeite. Gut wäre natürlich nich, wenn du das Buch "Mircosoft Windows Programmierung für Experten" von Jeffrey Richter hättest, da steht das mehr oder weniger ausführlich drin beschrieben.

[endeffects]

naja ich denke das übersteigt meine möglichkeiten ein wenig
zur zeit, ich werd versuchen die aufgaben für jeden thread
beim erzeugen zu übergeben