Zitat von Dax:

Genau das ist der Sinn der Critical Sections: man kommt erst dann rein, wenn alle anderen draussen sind - in der Zwischenzeit wartet man darauf, reinzukommen. Bei meinem Beispiel sind die Zeiten innerhalb der CS allerdings so kurz, dass man sich darum keine Gedanken machen muss

Aber theoretisch, wenn das jetzt mehr als kurz wäre.
Ich dachte an so was:

markieren

Code:

wenn <Critical>.KannBetreten dann
beginne
  <Critical>.Betrete;
  ...
  <Critical>.Verlasse;
beende

Zitat von Dax:

Zitat von xZise:

PS: Meine Hilfe funktioniert gerade nicht: Welche Unit ist CriticalSection?

SyncObjs glaub ich heisst die...

Danke Richtig

MfG
xZise

Edit #1

PS: Es gibt die Funktion "TryEnter". Scheiße! Warum funktioniert die Hilfe nicht. Tuts damit? Und reicht dann das?

markieren

Delphi-Quellcode:

procedure TSearchThread.SetFile(AFile: string);
begin
  if FCritical.TryEnter then
  begin
    FFile := AFile;
    FCritical.Leave;
  end;
end;

Zitat von xZise:

Edit #1

PS: Es gibt die Funktion "TryEnter". Scheiße! Warum funktioniert die Hilfe nicht. Tuts damit? Und reicht dann das?

zusammenfalten · markieren

Delphi-Quellcode:

procedure TSearchThread.SetFile(AFile: string);
begin
  if FCritical.TryEnter then
  begin
    //try
    FFile := AFile;
    //finally
    FCritical.Leave;
    //end;
  end;
end;

Ja, das müsste funktionieren - allerdings solltest du den kommentiert eingefügten Resourcenschutzblock immer dazuschreiben.

Immer, bei Enter und Leave?

MfG
xZise

PS: Ich habe mich noch nicht so sehr mit Multi-/Dualthreading beschäftigt

Zitat von xZise:

Immer, bei Enter und Leave?

Ja, immer, wenn du Resourcen holst und wieder freigeben musst - und ja, ich hab' sie vorhin auch vergessen. Wenn dein CS-Code eine Exception wirft, kommt es nie zum Leave, also kann kein Thread je wieder in diese CS eintreten, solange das Programm läuft.

So, ich melde mich auch mal wieder: Ich finde es irgendwie aus Prinzip besser, dem Hauptthread zu signalisieren, dass er etwas tun soll, als dass dieser ständig prüft, ob es neue Daten gibt.
Die neue SetFile-Implementierung würde ich umbenennen und nicht als Zugriffsroutine für das Property verwenden. Es widerspricht irgendwie dem Sinn eines Setters, wenn das Feld nur manchmal gesetzt wird. Das war mein kurzer Kommentar zum Thema "saubere Programmierung".

Um eines klarzustelen: Dieser Beitrag sollte nicht als "Meckerei" an Dax' Vorschlag verstanden werden. Es steht natürlich jedem frei, die Methode zu verwenden, die er für besser hält.