Zitat von Uwe Raabe:

So wohl nicht, aber das hier:

markieren

Delphi-Quellcode:

type
  TRec = packed record
    B: Byte;
    A: Integer;
  end;

führt dazu, daß A eher nicht auf einer der CPU genehmen Speichergrenze liegt und die damit zwei Zyklen zum Schreiben braucht. Zwischen diesen beiden Zyklen kann aber ein Lesezugriff (ebenfalls zwei Zyklen) erfolgen. Das hängt aber auch konkret von der verwendeten CPU ab.

Das ist ärgerlich. Sollte sowas nicht irgendwo in der x86-64 ISA spezifiziert sein? Ich erwarte ja schon irgendwie konstantes Verhalten auf allen x86 CPUs, wenn ich ein MOV ausführe.

Zitat von Zacherl:

Das ist ärgerlich. Sollte sowas nicht irgendwo in der x86-64 ISA spezifiziert sein? Ich erwarte ja schon irgendwie konstantes Verhalten auf allen x86 CPUs, wenn ich ein MOV ausführe.

Für x86 CPUs ist das auch einheitlich. Lediglich das Modulo der Startadresse für einen Ein-Zyklus-Zugriff ist zwischen 32- und 64-Bit unterschiedlich. Es gibt aber ja auch noch andere CPUs.

Das ist eine Frage der Ausrichtung...

Wenn Du mit {$A1} arbeitest ist es nicht sicher...

Wie ich gelesen haben übrigens auch nicht zu 100% bei einem Interger. Also lieber ein Interlock oder CS

Mavarik

Zitat von Sir Rufo:

Dann hat man auch einen Erfahrungswert und wird noch viel ruhiger

Erfahrungswerte sind bei Speichersemantik kritisch zu sehen. Fehler sind meisten ziemlich subtil, treten selten auf und sind schlecht reproduzierbar.
Es ist in 99% der Fälle besser die entsprechenden Bibliotheksfunktionen und Datentypen (richtig ausgerichtet) für atomare Zugriffe zu benutzen.

Und es nicht nur der Speicher selbst, auch der Compiler und Out-Of-Order-Execution kann dir reinpfuschen:

markieren

Delphi-Quellcode:

// Thread 1
ptr = Class.create():
ptr.value = 1337;
global_ptr = ptr;

markieren

Delphi-Quellcode:

// Thread 2
write(global_ptr.foo); // 1337?

Der Compiler weiß nicht, dass global_ptr von mehreren Threads benutzt wird und ordnet das wegen Optimierung so um (oder der Prozessor macht das; warum auch nicht):

markieren

Delphi-Quellcode:

// Thread 1
ptr = Class.create():
global_ptr = ptr;
ptr.value = 1337;

Den Fehler finde erst mal

Die Bibliotheksfunktionen sind entweder dem Compiler bekannt oder zumindest undurchsichtig, so dass er solche Spielchen lässt. Intern wird da sichergestellt, dass der Prozessor nichts umordnet (Memory Barriers oder andere Tricks).


Wenn es nur um Sachen geht, die schiefgehen können (z.B. Integer für Fortschrittsanzeige auslesen) mag das alles gut gehen. Alles darüber hinaus sollte man vorsichtig angehen.

Verdammt, dann habe ich wohl etwas Arbeit vor mir

Wie gehe ich am besten bei Enumtypen vor? Alles mit $Z4 deklarieren und dann immer die Integer Variante von InterlockedExchange benutzen dürfte die sicherste Methode sein oder? Gibt es analog hierzu auch eine Möglichkeit "ranged types" auf eine bestimmte Größe zu forcen?

markieren

Delphi-Quellcode:

type
  TRangedType = 0..1023;

Zitat von Zacherl:

Verdammt, dann habe ich wohl etwas Arbeit vor mir

Häh, wieso das denn? Pack die Felder in eine Klasse, gibt der Klasse ein Synchro-Mechanismus an die Hand und dann geht es ab.

zusammenfalten · markieren

Delphi-Quellcode:

TFoo = class
private
  FCS : TCriticalSection;
  FValue : string;
  function GetValue : string;
  procedure SetValue(const Value : string) : string;
public
  constructor Create;
  destructor Destroy; override;

  property Value : string read GetValue write SetValue;
end;

constructor TFoo.Create;
begin
  inherited;
  FCS := TCriticalSection.Create;
end;

destructor TFoo.Destroy;
begin
  FreeAndNil( FCS );
  inherited;
end;

function GetValue : string;
begin
  FCS.Enter;
  try
    Result := FValue;
  finally
    FCS.Leave;
  end;
end;

procedure SetValue(const Value : string) : string;
begin
  FCS.Enter;
  try
    FValue := Value;
  finally
    FCS.Leave;
  end;
end;

Klar, das ist sicherlich ein brauchbarer Ansatz (den ich auch partiell schon implementiert hatte). Allerdings habe ich gelesen, dass Critical Sections nicht umbedingt super performant sind. Zumindest bei den Werten, die alle paar Milisekunden aktualisiert werden, wollte ich lieber die Interlocked Funktionen verwenden.

Kann man bezüglich der "ranged types" was machen, oder bin ich hier gezwungen Critical Sections zu benutzen?

Zitat von Zacherl:

Klar, das ist sicherlich ein brauchbarer Ansatz (den ich auch partiell schon implementiert hatte). Allerdings habe ich gelesen, dass Critical Sections nicht umbedingt super performant sind. Zumindest bei den Werten, die alle paar Milisekunden aktualisiert werden, wollte ich lieber die Interlocked Funktionen verwenden.

Kann man bezüglich der "ranged types" was machen, oder bin ich hier gezwungen Critical Sections zu benutzen?

Du brauchst einen Synchro-Mechanismus (den man - wie hier exemplarisch gezeigt - mit einer CriticalSection machen kann, oder mit TMonitor , oder, oder, oder, oder, ..... )

Welchen, das hängt eben davon ab, was da atomar ablaufen soll/muss. Ein TInterlocked geht eben nur für einen Wert und eben nur für bestimmte Typen
System.SyncObjs.TInterlocked

Und die Synchronisationsobjekte (unter System.SyncObjs) leiten sich doch alle von einer gemeinsamen Oberklasse ab. Wenn du später eine die TCriticalSection gegen etwas anderes austauschen willst, ist das nur eine Sache- Ich hätte Sir Rufos Ansatz noch um eine Typdefinition erweitert:

zusammenfalten · markieren

Delphi-Quellcode:

TFoo = class
protected type
   TSyncObj = TCriticalSection;
private
   FCS : TSyncObj;
   FValue : string;
   function GetValue : string;
   procedure SetValue(const Value : string) : string;
public
   constructor Create;
   destructor Destroy; override;

   property Value : string read GetValue write SetValue;
end;

Dann kannst du später alles in einer Zeile austauschen.

Zitat von Sir Rufo:

Ein TInterlocked geht eben nur für einen Wert und eben nur für bestimmte Typen
System.SyncObjs.TInterlocked

Ja das ist klar. Sind im Prinzip alles triviale Typen, die ich syncen will (1, 2, 4 und 8 Byte). Habe mir über eine Helper Class bereits noch ein paar Funktionen für UInt32 und UInt64 hinzugefügt, da es die unsigned Varianten leider nicht standardmäßig gibt (dank des var Parameters kann man auch nicht einfach casten).

Bin momentan am sichten, auf welche Felder in welcher Form von wo aus zugegriffen wird.

Momentan habe ich vier verschiedene Modi:

1. Read im internen Thread UND externen Threads, Write nur im internen Thread
   • Benötigte eine gesyncte Read Funktion, eine ungesyncte Read Funktion (für den internen Thread aus Performancegründen) und eine gesyncte Write Funktion
2. Read im internen Thread UND externen Threads, Write im internen UND externen Threads
   • Benötigte eine gesyncte Read Funktion und eine gesyncte Write Funktion
3. Read im internen Thread UND externen Threads, Write einmal im Konstruktor bevor irgendein Zugriff von irgendwo möglich ist
   • Muss nicht synchronisiert werden
4. Read nur in externen Threads, Write einmal im Konstruktor bevor irgendein Zugriff von irgendwo möglich ist
   • Muss nicht synchronisiert werden

Hoffe ich habe da grade keine Logikfehler eingebaut.

Zitat von Der schöne Günther:

Und die Synchronisationsobjekte (unter System.SyncObjs) leiten sich doch alle von einer gemeinsamen Oberklasse ab. Wenn du später eine die TCriticalSection gegen etwas anderes austauschen willst, ist das nur eine Sache- Ich hätte Sir Rufos Ansatz noch um eine Typdefinition erweitert

Die Interlocked Funktionen sind allerdings nicht in der selben Form in einem SyncObject gekapselt. Austauschen werde ich die Synchronisierungsobjekte allerdings wohl eh niemals.