TThread - Sleep

[JoltinJoe]

Das hat sich ein Fehler beim kopieren eingeschlichen... "CheckCondition" kann außer Acht gelassen werden, habe es auch im Vor-Thread entfernt...

Nach dem Start der Threads schläft das ganze Programm sofort und danach führen alle Threads "MEINE_ANDEREN_PROCEDUREN" aus.



Edit:

Wenn ich die 100 Aufgaben anstatt auf 100 Threads nur auf 1 Thread lege dann klappt es. 50 werden ausgeführt, dann wird geschlafen und dann kommen die anderen 50.

Wenn ich die 100 Aufgaben auf 100 Threads lege dann wird erst geschlafen und dann werden alle 100 Threads mit einem mal abgearbeitet.

[JoltinJoe]

Delphi-Quellcode:

procedure TMyOwnThread.HighCondition;
begin
  FetchedCount:=FetchedCount+1;
end;

procedure TMyOwnThread.ResetCondition;
begin
  FetchedCount:=0;
end;

procedure TMyOwnThread.WriteResults;
begin
  Form1.Memo1.Lines.Add('blaa');
end;

procedure TMyOwnThread.Execute;
begin
  while not Terminated do
  begin
    Synchronize(HighCondition);
    if FetchedCount>50 then
    begin
      Sleep(10000);
      Synchronize(ResetCondition);
    end;
    Synchronize(WriteResults);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Thread: TMyOwnThread;
  ThreadCount: Integer;
begin
  ThreadCount:=100;
  for i:=0 to ThreadCount-1 do
    begin
      Thread:=TMyOwnThread.Create(True);
      Thread.FreeOnTerminate := True;
      Thread.Resume;
    end;
end;

Habe hier nochmal den kompletten Code zur Veranschaulichung gekürzt ..

[xZise]

Moin,
Und so funktioniert er nicht? Weil ich kann da keine Probleme erkennen. Wobei natürlich 100 Threads via Sync schon heftig ist.

Wäre da nicht eventuell eine TCriticalSection was?

MfG
Fabian

[JoltinJoe]

Die 100 habe ich frei aus der Luft gegriffen, wieviele es werden ist noch nicht bekannt, denke mal um die 20 Threads.

Ich seh da auch kein Problem ;) Aber wie gesagt, es funktioniert nicht... (Habs auch schon mit 3, 10, 20 Threads versucht)

[ChrisE]

Hallo JoltinJoe,

also soweit ich das in dem gekürzten Beispiel aus dem letzten Post mit den Sourcen sehen kann, macht jeder Thread hauptsächlich arbeit in der Zeit des MainThreads (Synchronize). Natürlich ist das ein gekürztes Beispiel, aber dieses Beispiel zeigt seht gut, dass Threads nicht immer die Lösung sind.

Ich würde versuchen, den Ansatz von xZise zu verfolgen und ResetCondition und HighCondition durch CriticalSections ab zu sichern. Das könnte etwas bringen.
Des weiteren würde ich versuchen WriteResults ebenso in einen Speicherbereich zu schreiben, denn du mit einer CriticalSection absichern kannst und dann deine Application z.B. per PostMessage darüber informierst, dass in dem Speicher etwas liegt, dass man auf der Oberfläche aus geben sollte.

Delphi-Quellcode:

TMyThreadContainer = class
private
  FCSFetchCount: TCriticalSection;
  FCSResults: TCriticalSection;
  FFetchCount: Integer;
public
  procedure Start(AInfoFrom: TForm);
  procedure HighCondition;
  procedure ResetCondition;  
published
  property FetchCount: Integer read GetFetchCount write SetFetchCount;
end;

TMyOwnThread = class(TThread)
private
  FOwnerContainer: TMyThreadContainer;
//
public
  property OwnerContainer: TMyThreadContainer read FOwnerContainer write FOwnerContainer; 

//...

function TMyThreadContainer.GetFetchCount: Integer;
begin
  FCSFetchcondition.Enter;
  try
    result:=FFetchCount;
  finally
    FCSFetchCount.Leave;
  end;
end;

procedure TMyThreadContainer.SetFetchCount(Value: Integer);
begin
  FCSFetchCount.Enter;
  try
    FFetchCount:=Value;
  finally
    FCSFetchCount.Leave;
  end;
end;

procedure TMyThreadContainer.HighCondition;
begin
  FetchCount := FetchCount +1;
end;

procedure TMyThreadContainer.ResetCondition;
begin
  FetchCount := 0;
end;

// ....

procedure TMyOwnThread.Execute;
begin
  while not Terminated do
  begin
    FOwnerContainer.HighCondition;
    if FOwnerContainer.FetchCount>50 then
    begin
      Sleep(10000);
      FOwnerContainer.ResetCondition;
    end;
    FOwnerContainer.WriteResults('bla bla');
  end;
end;

Wie gesagt, hier nur grob das Beispiel. Aber WriteResults kannst du noch absichern durch eine CS und dort halt das InfoForm per PostMessage informieren, dass es Ergebnisse zum abholen gibt. Der Container kann dann auch das Starten und ggf. auch das Abbrechen der Threads übernehmen. Das liegt dann an Dir :-)

Greez, Chris

[JoltinJoe]

Hm das sieht schonmal interessant aus aber dann stellt sich trotzdem die Frage warum Sleep unter den Umständen nicht funktioniert. Ohne Sleep werden die Aufgaben parallel und ohne Probleme ausgeführt. Also sollte Synchronize eigentlich die richtige Wahl gewesen sein ?

[Sir Rufo]

Nein, Synchronize bremst einen Thread immer aus.
Eine CriticalSection ist da wesentlich besser, vor allem weil beim Setzen eines Wertes ein Synchronize völlig überflüssig ist.
Wenn du mit deinem Fahrrad fährst, hälst du auch nicht an, nur um dich am Kopf zu kratzen.

Ich versuche immer ein Synchronize zu vermeiden und arbeite mit CriticalSections und PostMessage oder Polling. Dadurch bleibt der Thread autonom und performant.

Und ein Sleep in einem Thread geht dann auch :-)

[JoltinJoe]

Gut dann werd ich das aufjedenfall probieren ! Bleibt trotzdem die Frage warum Sleep mit Synchronize nicht funktionert :)

[ChrisE]

Hallo JoltinJoe,

wie Sir Rufo schon gesagt hat ist da ein großer Unterschied. Synchronize sorgt quasi dafür, dass die Methode durch den Haupt-Thread ausgeführt wird. Eine CriticalSection sorgt nur dafür, dass dieser Bereich nur von einem Thread gleichzeitig "betreten" wird.

Aber du hast recht, mir will es gerade auch noch nicht in den Kopf, warum Sleep in der execute-Methode nicht funktioniert bzw. den Haupt-Thread zum Stillstand bringt.

Greez, Chris

[JoltinJoe]

Die CriticalSection ist klar, jedoch habe ich jetzt noch nicht verstanden wie ich die Daten dann aufs Formular bringe. PostMessage ?! :pale:


PS: Mal was anderes, warum wird häufig ein führendes F vor Variablen etc genutzt ?