TCriticalSection: Einmal global oder immer lokal erstellen?

[Sir Rufo]

Zitat von Luckie:

CriticalSections müssten schon global sein, weil alle Thread sie ja kennen müssen.

Nein, müssen schon mal gar nicht. Und was interessiert es den Thread A wenn in Thread B Daten geändert werden. Möglich ja, aber warum sollte man sich eine Blockade für alle Threads bauen?
Ich dachte immer, die sollen so schnell als möglich ihren Job machen und da ist das Ausbremsen doch völlig kontraproduktiv.

Zitat von Oberlehrer:

Eine CriticalSection muss in dem Kontext vorhanden sein, in dem auch die Daten liegen, die durch die CriticalSection geschützt werden sollen.

Bei einer globalen Variable muss man eine globale CriticalSection haben, aber wer benutzt schon globale Variablen.

Um den Datenzugriff zu schützen reicht es nicht nur den Schreibzugriff abzusichern, sondern auch den Lesezugriff!
Denn was soll denn zurückgeliefert werden, wenn während des Lesens von einem anderen Thread der Wert geändert wird? Die Hälfte vom alten und die Hälfte vom neuen Wert?

Hier mal das Beispiel für eine Klasse mit einer geschützten Eigenschaft.
(Das Erzeugen und Zerstören der CS lasse ich mal weg)

FALSCH:

Delphi-Quellcode:

TMyClass = class
strict private
  _CS : TCriticalSection;
private
  fMyValue : string;
  procedure SetMyValue( const Value : string );
public
  property MyValue : string read fMyValue write SetMyValue;
end;

procedure TMyClass.SetMyValue( const Value : string );
begin
  _CS.Enter;
  try
    fMyValue := Value; // geschützter Schreib-Zugriff
  finally
    _CS.Leave;
  end;
end;

RICHTIG:

Delphi-Quellcode:

TMyClass = class
strict private
  _CS : TCriticalSection;
private
  fMyValue : string;
  function GetMyValue : string;
  procedure SetMyValue( const Value : string );
public
  property MyValue : string read GetMyValue write SetMyValue;
end;

function TMyClass.GetMyValue : string;
begin
  _CS.Enter;
  try
    Result := fMyValue;  // geschützter Lese-Zugriff
  finally
    _CS.Leave;
  end;
end;

// Schreibzugriff geschützt

procedure TMyClass.SetMyValue( const Value : string );
begin
  _CS.Enter;
  try
    fMyValue := Value; // geschützter Schreib-Zugriff
  finally
    _CS.Leave;
  end;
end;

[jensw_2000]

Zitat:

Um den Datenzugriff zu schützen reicht es nicht nur den Schreibzugriff abzusichern, sondern auch den Lesezugriff!
Denn was soll denn zurückgeliefert werden, wenn während des Lesens von einem anderen Thread der Wert geändert wird? Die Hälfte vom alten und die Hälfte vom neuen Wert?

Das könnte 1-2 "Effekte" erklären.

Verstehe ich das richtig, dass in dem Beispiel "nur" der Codeabschnitt im Getter und Setter durch die CS gelockt wird und nicht das Feld "fMyValue"?

Wenn dein Beispiel "TMyClass" von TThread abgeleitet wäre, müsste man demnach auch klassenintern (besonders in TThread.Execute) darauf achten, dass man immer über die Property auf fMyValue zugreift und nie direkt. Richtig?

[Luckie]

Zitat von Sir Rufo:

Zitat von Luckie:

CriticalSections müssten schon global sein, weil alle Thread sie ja kennen müssen.

Nein, müssen schon mal gar nicht. Und was interessiert es den Thread A wenn in Thread B Daten geändert werden.

Ich bin natürlich davon ausgegangen, dass die Threads auf die selben Daten zugreifen. Aber ich dachte das wäre klar.

[Sir Rufo]

Zitat von jensw_2000:

Wenn dein Beispiel "TMyClass" von TThread abgeleitet wäre, müsste man demnach auch klassenintern (besonders in TThread.Execute) darauf achten, dass man immer über die Property auf fMyValue zugreift und nie direkt. Richtig?

Jeder Zugriff auf Daten, die auch von ausserhalb (hier das Feld fMyValue der Thread-Instanz über eine public property) erreicht werden können, sollte nur geschützt erfolgen.

Das muss aber nicht ausschließlich über die Property erfolgen.

Delphi-Quellcode:

procedure TMyThread.Execute;
begin

  MyValue := 'geschützt';

  fMyValue := 'NICHT geschützt - es droht eine AV';

  CS.Enter;
  try
    fMyValue := '';
    for i := 1 to 5 do
      fMyValue := fMyValue + 'geschützt';
  finally
    CS.Leave;
  end;

end;

[schlecki]

Ich benutze auch immer gern den TMultiReadExclusiveWriteSynchronizer - langer Name

Der hat den Vorteil, dass sich gleichzeitig Lesen lässt, aber das Schreiben exklusiv erfolgen muß - naja, der Name verräts eigentlich auch ^^
Wichtig ist nur, dass man _immer_!!! entweder den Lese- oder den Schreibzugriff aufrufen darf. Ansonsten kann es zu deadlocks kommen.

[BUG]

Zitat von schlecki:

Ich benutze auch immer gern den TMultiReadExclusiveWriteSynchronizer - langer Name

Der hat den Vorteil, dass sich gleichzeitig Lesen lässt, aber das Schreiben exklusiv erfolgen muß - naja, der Name verräts eigentlich auch ^^

Das Ding löst halt ein klassisches Synchronisierungsproblem. Selbst wenn man ein abstraktes Leser-Schreiber-Problem hat, ist es nicht ganz trivial, das "fair" und schnell für mehrere Leser und Schreiber zu lösen.

Wenn sich da eine fertige/erprobte Klasse anbietet, sollte man sie auch nutzten