CriticalSections wie verwenden?

[Bummi]

Um bei Deinem Beispiel zu bleiben
Point.x
Point.y
in einer CriticalSection, wenn der lesende sich nicht darum schert daß es da eine (ihm unbekannte CS) gibt liest er einfach den Wert aus , egal ob der Thread es in eine CS gepackt hat oder nicht.

[Bummi]

@assabard
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. aber wofür benötigt er dann ene CS?

[Sir Rufo]

Zitat von Bummi:

@assabard
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. aber wofür benötigt er dann ene CS?

Weil die Queue aus einem anderen Thread-Kontext abgefragt wird (Synchronize/Queue)

[Bummi]

Jepp, aber hier kommen wir wieder zu dem Punkt daß die Abfrage sich nicht für Deine lokalen CS interessiert.
wenn Du nochmals mein Beispiel aus
http://www.delphipraxis.net/156304-v...ml#post1064523
#26 heranziehst
Meine Vorstellung einer CS basiert darauf daß ein Codeabschnitt markiert Windows mitgeteilt wird. Wenn ein anderer Thread versucht diesen Codeabschnitt zu betreten wird dies nur ermöglicht wenn kein anderer Thread sich gerade darin aufhält. Wenn die Markierung jedes mal eine andere ist wie soll Windows hier eingreifen.

[Bummi]

Zitat:

Es ist egal, ob das von einer lokalen (im Thread verankerten) oder globalen CS geschützt wird. Es muss aber geschützt werden.

ich bin völlig bei Dir, aber ohne Kenntnis / Beachtung des CS wir jeder zu jedem Zeitpunkt gegf. Müll auslesen(der Speicher ist ja nicht geschützt, Windows verhindert ja nur die Reentranz in ihm bekannte CS) .

[jaenicke]

Zitat von Bummi:

wenn Du nochmals mein Beispiel aus
http://www.delphipraxis.net/156304-v...ml#post1064523
#26 heranziehst

Das ist aber ein vollkommen anderer Fall als der aus seinem Beispiel. Hier hast du eine globale Variable, auf die eben von verschiedenen Stellen aus zugegriffen wird. Das ist ja etwas anderes.

In seinem Beispiel befindet sich das Feld, auf das zugegriffen wird, innerhalb des Threads. Und es wird ausschließlich über die kritische Sektion genau dieses Threads zugegriffen. Und eben nicht durch verschiedene Threads und mehrere Sektionen. Denn beim Zugreifen verwendet auch der andere Thread die kritische Sektion des Zielthreads und nicht seine eigene.

[Bummi]

@jaenicke
Nochmals Danke
dies ist mir meine ich klar, aber wofür dann die CS wenn sich ohnehin alles innerhalb des Threads abspielt.
Ich scheine hier tatsächlich einen resistenten Hänger zu haben, mir erschließt sich der Sinn der lokalen CS nicht, die ja nur berücksichtigt werden können wenn ein potentieller "Zugreifer" davon Kenntnis hat.

[jaenicke]

Zitat von Bummi:

aber wofür dann die CS wenn sich ohnehin alles innerhalb des Threads abspielt.

Tut es ja nicht. Ein anderer Thread (z.B. der Hauptthread) greift über die Eigenschaften des Zielthreads aus seinem Kontext zu. Innerhalb des Getters bzw. Setters wird dann über die kritische Sektion des Zielthreads, zu dem die Eigenschaft gehört, verhindert, dass gleichzeitig von innerhalb des Zielthreads darauf zugegriffen wird.

[Assarbad]

Zitat von Bummi:

dies ist mir meine ich klar, aber wofür dann die CS wenn sich ohnehin alles innerhalb des Threads abspielt.

Tut es nicht zwangsläufig.

Wir haben Threads A und B sowie Ressourcen a(A) und b(B) die jeweils dem Thread gehören. A besitzt eine CS die den Zugriff auf a(A) regelt und B eine CS die den Zugriff auf b(B) regelt. Soweit kommst du sicher mit, richtig?

Wenn nun aber Thread A einen Zugriff auf die Instanz von B macht, ruft er (im eigenen Kontext, also dem Kontext von Thread A ... das ist der potentielle Konflikt) die Getter oder Setter von B auf (aber mit Self == B). Dieser Getter oder Setter benutzt aber auch die CS welche den Zugriff auf b(B) regelt und damit ist alles in Ordnung.

[Sir Rufo]

Zitat von Bummi:

Jepp, aber hier kommen wir wieder zu dem Punkt daß die Abfrage sich nicht für Deine lokalen CS interessiert.
wenn Du nochmals mein Beispiel aus
http://www.delphipraxis.net/156304-v...ml#post1064523
#26 heranziehst
Meine Vorstellung einer CS basiert darauf daß ein Codeabschnitt markiert Windows mitgeteilt wird. Wenn ein anderer Thread versucht diesen Codeabschnitt zu betreten wird dies nur ermöglicht wenn kein anderer Thread sich gerade darin aufhält. Wenn die Markierung jedes mal eine andere ist wie soll Windows hier eingreifen.

Wenn ich Speicherbereich A schützen möchte, dann nehme ich dafür ein CS mit Namen CSA.
Ich muss nun gewährleisten, dass bei jedem Zugriff auf den Speicherbereich A die CS CSA betreten und danach wieder verlassen wird.

Das ist erstmal alles.

Windows ist es egal, wieviele CS ich benutze.

Jede Instanz von einer Klasse/Thread belegt einen bestimmten Speicherbereich. Erzeuge ich mit der Klasse/Thread eine CS kann ich damit genau den Speicherbereich vom der Klassen-/Thread-Instanz schützen.

Meine Vorgehensweise ist nun, dass alles in der Klasse/Thread, auf das von außen zugegriffen wird von eben so einer CS geschützt wird.

Delphi-Quellcode:

TMyThread = class( TThread )
  property Info : Int64 read GetInfo;
end;

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

Wenn ich jetzt auf die Property Info von der Thread-Instanz zugreife, warum sollte die dann nicht geschützt sein?
Es wird ein CS betreten, der Wert ausgelesen und die CS wieder verlassen.
Das diese CS-Instanz innerhalb der Thread-Instanz aufgehangen ist, ist völlig egal. Es ist eine CS.

Und schützen muss ich die mit einer CS, wenn ich den Wert der Property Info innerhalb von TMyThread.Execute beschreiben will

Delphi-Quellcode:

procedure TMyThread.Execute;
  begin
    ThreadCS.Enter;
    try
      FInfo := 20;
    finally
      ThreadCS.Leave;
    end;
  end;