![]() |
AW: TThread - Sleep
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. |
AW: TThread - Sleep
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 .. |
AW: TThread - Sleep
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 ![]() MfG Fabian |
AW: TThread - Sleep
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) |
AW: TThread - Sleep
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:
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 :-)
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; Greez, Chris |
AW: TThread - Sleep
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 ?
|
AW: TThread - Sleep
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 :-) |
AW: TThread - Sleep
Gut dann werd ich das aufjedenfall probieren ! Bleibt trotzdem die Frage warum Sleep mit Synchronize nicht funktionert :)
|
AW: TThread - Sleep
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 |
AW: TThread - Sleep
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 ? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz