CriticalSections wie verwenden?

[Bummi]

Umzug der CriticalSection Diskusion aus
verhindern: Klick auf Titelleiste stoppt Programm #27

http://www.delphipraxis.net/156304-v...ml#post1064523

@Sir Rufo

Zitat:

Aus diesem Grund hänge ich die Instanz von TCriticalSection auch direkt an den Thread, um dessen Properties so zu schützen, dass kein gleichzeitiger Zugriff darauf erfolgen kann. Mittels Getter und Setter wird dann automatisch die CS betreten/verlassen. Somit wird der Zugriff auf selbige extrem stressfrei.

Mir ist nicht ganz klar was Du damit schützt, die Bereiche innerhalb Deiner Klasse die nicht von anderen Threads erreicht werden können brauchen IMHO nicht mit einer CriticalSection gekapselt werden.

Wenn Du einen Bereich in eine CriticalSection packst mußt Du Dich so zumindest mein Kenntnissstand darauf verlassen können daß andere über die gleich CriticalSection darauf zugreifen.

Hast Du Punkt #26 aus o.g. Thread einmal nachvollzugen? Die Variable txt ist nur sicher zugreifbar wenn sich alle daran halten vor dem Zugriff ein und dieselbe CriticalSection zu verwenden.

[Assarbad]

Zitat von Bummi:

Wenn Du einen Bereich in eine CriticalSection packst mußt Du Dich so zumindest mein Kenntnissstand darauf verlassen können daß andere über die gleich CriticalSection darauf zugreifen.

Absolut korrekt. Nur wenn sich alle daran halten, hilft der kritische Abschnitt.

Zitat von Bummi:

Die Variable txt ist nur sicher zugreifbar wenn sich alle daran halten vor dem Zugriff ein und dieselbe CriticalSection zu verwenden.

Jupp.

Ich nehme allerdings an, daß hier nur die Ausdrucksweise unglücklich war. Wenn der Getter und Setter (oder ggf. nur Setter, je nach Datentyp) den kritischen Abschnitt benutzen, ist das ja nicht auf einen Thread beschränkt, wie die Aussage erstmal vermuten läßt.

[Bummi]

Zitat:

Ich nehme allerdings an, daß hier nur die Ausdrucksweise unglücklich war. Wenn der Getter und Setter (oder ggf. nur Setter, je nach Datentyp) den kritischen Abschnitt benutzen, ist das ja nicht auf einen Thread beschränkt, wie die Aussage erstmal vermuten läßt.

hier hakt es bei mir, wofür brauche ich hier dann lokale (innerhalb des Threads gültige) CriticalSections.

[Assarbad]

Zitat von Bummi:

hier hakt es bei mir, wofür brauche ich hier dann lokale (innerhalb des Threads gültige) CriticalSections.

Jupp, tut mir leid. Hatte das Originalthema nicht komplett gelesen und auch jetzt nur überflogen. Aber der Code bei dem jeder Thread seine eigene CS hat, ist natürlich Unsinn. Ein Synchronisationsobjekt funktioniert nur wenn alle das gleiche benutzen. Oder um Luckie zu zitieren:

Zitat von Luckie:

Wenn mehrere Threads aufeinander warten müssen, dann dürfen sie auch nur die gleiche CriticalSection nutzen. Das ist wie bei einer Ampelkreuzung, die darf auch nur von einer Schaltung gesteuert werden. Hätte jede Ampel ihre eigene Steuerung würde es krachen.

[Sir Rufo]

Zitat von Assarbad:

Zitat von Bummi:

hier hakt es bei mir, wofür brauche ich hier dann lokale (innerhalb des Threads gültige) CriticalSections.

Jupp, tut mir leid. Hatte das Originalthema nicht komplett gelesen und auch jetzt nur überflogen. Aber der Code bei dem jeder Thread seine eigene CS hat, ist natürlich Unsinn. Ein Synchronisationsobjekt funktioniert nur wenn alle das gleiche benutzen.

Hmmm, das sehe ich anders, wenn ich optimal laufenden Code erzeugen will mit der maximal möglichen Performance. Natürlich wird es auch mit einer externen CS funktionieren, aber eben nicht so performant wie es laufen könnte.

Beispiel:

Delphi-Quellcode:

GlobalCS : TCriticalSection;

TMyThread = class( TThread )
{...}
  Info : Int64;
end;

procedure TMyThread.Execute;
  begin
    while not Terminated do
      begin
        GlobalCS.Enter;
        try
          QueryPerformanceCounter( Info );
        finally
          GlobalCS.Leave;
        end;
      end;
  end;

MyThread1, MyThread2 : TMyThread;

procedure ImMainThread;
var
  ThInfo : Int64;
begin
  GlobalCS.Enter;
  // Beide Threads MyThread1, MyThread2 stoppen jetzt, weil sie ja 
  // GlobalCS nicht mehr betreten können.
  // Ich will aber nur von MyThread1 etwas wissen, warum soll MyThread2 dann gestört werden???
  try
    ThInfo := MyThread1.Info;
  finally
    GlobalCS.Leave;
  end;
end;

Meine Variante sieht so aus

Delphi-Quellcode:

TMyThread = class( TThread )
  ThreadCS : TCriticalSection;
  FInfo : int64;
{...}
  property Info : Int64 read GetInfo;
end;

function GetInfo : Int64;
  begin
    ThreadCS.Enter;
    try
      Result := FInfo;
    finally
      ThreadCS.Leave;
    end;
  end;

procedure TMyThread.Execute;
  begin
    while not Terminated do
      begin
        ThreadCS.Enter;
        try
          QueryPerformanceCounter( FInfo );
        finally
          ThreadCS.Leave;
        end;
      end;
  end;

MyThread1, MyThread2 : TMyThread;

procedure ImMainThread;
var
  ThInfo : Int64;
begin
  ThInfo := MyThread1.Info;
end;

Der Zugriff auf die Property ist wesentlich leichter und es wird nur der Thread gestört, den ich abfrage.

[Assarbad]

Zitat von Sir Rufo:

Hmmm, das sehe ich anders, wenn ich optimal laufenden Code erzeugen will mit der maximal möglichen Performance. Natürlich wird es auch mit einer externen CS funktionieren, aber eben nicht so performant wie es laufen könnte.

Nunja, Synchronisation muß aber nunmal sein.

Meine Delphikenntnisse sind ein wenig eingerostet, aber ich sehe in deinem Code keinen konkurrierenden Zugriff zwischen den Threads. Was willst du also beweisen? Daß dein Code sicher ist, wäre zumindest damit nicht (generell) bewiesen.

Zitat von Sir Rufo:

Greift Thread A auf eine Property aus Thread B zu, dann ist die Property von Thread B ja geschützt. Somit kann es einfach keine Zugriffsfehler geben, da diese immer geschützt sind.

Die Aussage macht allerdings in der Tat Sinn, wenn ein Zugriff so wie beschrieben stattfände.

Das was ich gesehen habe wäre aber ohnehin billiger mit Interlocked-Funktionen zu machen (zumindest bei den verwendeten Datentypen).

Zitat von Bummi:

Wenn Du für jede Instanz eine eigene CS erzeugst wie soll der Zugriff dann geschützt sein.

Wenn jeder Thread seine eigene Queue hat und mit der CS schützt, dann macht es schon so Sinn. Da der Zugriff über Getter/Setter stattfindet, hat alles seine Ordnung.

Zusammenfassend:

Also, es gibt nicht nur eine Queue, somit ist die Queue auch pro Thread schützbar (so wie gezeigt).

[jaenicke]

Zitat von Bummi:

hier hakt es bei mir, wofür brauche ich hier dann lokale (innerhalb des Threads gültige) CriticalSections.

Wenn es um den Zugriff auf Resourcen des Threads geht (wie in dem Beispiel, um das es geht), dann reicht auch eine threadlokale kritische Sektion. Denn da im Getter und Setter diese genauso benutzt wird wie innerhalb des Threads, ist kein paralleler Zugriff auf das private Feld hinter Getter bzw. Setter möglich.

Der Zugriff aus einem anderen Thread passiert ja über die Getter und Setter bzw. die entsprechende Property und damit wird der Zugriff auch effektiv geschützt. Und dabei muss dennoch nicht mit dem Hauptthread synchronisiert werden, sondern es wird nur die kritische Sektion benutzt.

Nicht funktionieren tut es, wenn der Zugriff auf eine Resource eben nicht immer über die selbe kritische Sektion erfolgt. Aber das ist hier nicht der Fall, da jeder Thread zwar eine eigene kritische Sektion, aber auch eine eigene zu schützende Resource hat.

[Bummi]

Danke , aber wenn jeder Thread seien eigen CriticalSection erzeugt wie ist dann ein übergreifender Zugriff gewährleistet, oder da dies ja nicht eigentlich das Problem hier ist, wofür benötige ich die Threadinternen CS überhaupt?

[Sir Rufo]

Zitat von Bummi:

Danke , aber wenn jeder Thread seien eigen CriticalSection erzeugt wie ist dann ein übergreifender Zugriff gewährleistet, oder da dies ja nicht eigentlich das Problem hier ist, wofür benötige ich die Threadinternen CS überhaupt?

a. Performance
b. der Thread selber ist per Definition auch threadsafe für Zugriffe von außen (über die Properties)

meine Threads übernehme ich in jedes beliebige Projekt und benutze diese ohne mich um irgendeine CS weiter zu kümmern, dann das regelt der Thread ja in sich selber.

Greift Thread A auf eine Property aus Thread B zu, dann ist die Property von Thread B ja geschützt. Somit kann es einfach keine Zugriffsfehler geben, da diese immer geschützt sind.

Ist quasi die Merz-Spezial-Dragee-Methode (Wahre Schönheit kommt von innen)

[jaenicke]

Zitat von Bummi:

Danke , aber wenn jeder Thread seien eigen CriticalSection erzeugt wie ist dann ein übergreifender Zugriff gewährleistet, oder da dies ja nicht eigentlich das Problem hier ist, wofür benötige ich die Threadinternen CS überhaupt?

Der übergreifende Zugriff auf die Resource des Threadobjektes passiert ja über die dazu gehörende kritische Sektion.

Das heißt es geht nicht darum, auf die selbe Resource mit verschiedenen kritischen Sektionen zuzugreifen, wie du offenbar vermutest.