hey there

Eine Frage, die mich schon länger beschäftigt: Wann muss ein Thread genau synchronisiert werden? Grundsätzlich gilt ja, dass jeder Zugriff auf die VCL über Synchronize/Critical Sections/SendMessage erfolgen muss. Aber kann ich z.B. einen TThread in ein public Field von ihm schreiben lassen und dann im Haupt-Thread sporadisch (z.B. über einen Timer) lesend darauf zugreifen?

Gruss
Shaman

ich sag es einfach mal so:

Solange 100%ig sichergestellt werden kann, daß nicht wärend ein Thread irgendwas ändert/speichert ein anderer Thread irgendwie (egal ob Lesend, oder Schreibend) auf diesen Wert zugreift, dann brauchst du nicht zu synchronisieren.

Gleichzeitige Lesezugriffe sind (solange dabei intern nichts geändert wird) unproblematisch.


z.B. wird bei (dynamischen) Strings beim kopieren(lesen) mit S:=S2; intern ein referenzzähler verändert, daher sind strings eben nicht threadsicher.




Bei kleinen Werten (so is Registerbreie, also meißt 32 Bit) kann man den Prozessor auch mal kurzzeitig in den "Einzelprozessmodus" umschalten ... somit können wärend des änderns keine anderen Threads zugreifen.
Allerdings kann man dieses nur wärend eines einzigen ASM-Befehls veranlassen.

Darum nutze ich gerne mal iniges aus der angehängten Unit.

um gleichzeitiges Schreiben zu verhindern:
- wenn nur Einer ließt
LockedInc, LockedDec, LockedSet

und bei gleichzeitigem Lesen:
- wenn Mehrere lesen
LockedGet


-wenn jeweils nur Einer schreibt und ein Anderer ließt, dann halt abhängig, ober mehr gelesen (hier Inc Dec Set verwenden), oder geschrieben (Get verwenden) wird.

Das heisst, wenn ein Thread in seine Integer-Properties schreibt, die ich danach im Hauptthread auslese, gehört das in eine Critical Section?

Zitat von Shaman:

Das heisst, wenn ein Thread in seine Integer-Properties schreibt, die ich danach im Hauptthread auslese, gehört das in eine Critical Section?

jupp

Oder (wie ich grad noch oben angehängt hab) du löst das anders ... bei 'nem integer geht dieses ja.

allerdings nicht über ein Property ... du benötigst dann schon einen "echten" Zugriff auf diese Variable.
Mit den Setter-Methoden den neuen Integer-Wert eintragen und in der VCL dann ganz normal auf diese Variable zugreifen (wenn da nur gelesen wird)

Das sieht gut aus, vielen Dank...

Also bin ich mit

zusammenfalten · markieren

Delphi-Quellcode:

type
  TThreadEx = class(TThread)
  private
    FValue: Integer;
    function GetValue: Integer;
    procedure SetValue(const Value: Integer);
  public
    property Value: Integer read GetValue write SetValue;
  end;

function TThreadEx.GetValue: Integer;
begin
  Result:= LockedGet(FValue);
end;

procedure TThreadEx.SetValue(const Value: Integer);
begin
  LockedSet(FValue, Value);
end;

auf der sicheren Seite?

Ja.

Aber wie gesagt, in diesem Fall reicht auch nur der Setter aus.

Denn man muß bedenken, daß ja für 'nen winzigen augenblick die anderen Threads eingefrohren werden, wenn man diese Variante nutzt.

Da gleichzeitiges Lesen ja hierbei zu keinen Problemen führt würde es so auch noch funktionieren.
Wobei hier wärend des Lesens der Prozessor nicht umgestellt wird

zusammenfalten · markieren

Delphi-Quellcode:

type
  TThreadEx = class(TThread)
  private
    FValue: Integer;
    procedure SetValue(const Value: Integer);
  public
    property Value: Integer read FValue write SetValue;
  end;

procedure TThreadEx.SetValue(const Value: Integer);
begin
  LockedSet(FValue, Value);
end;