Zitat von Zacherl:

Bei zwei Threads die beide schreiben, muss ich doch theoretisch sogar auch nichts absichern, sofern der neue Wert nicht vom alten Wert abhängt oder?

Schreib dir einfach einen Thread, der immer wieder in eine "globale" Variable einen zufälligen Wert schreibt.

Schreibe einen weiteren, der aus dieser Variable liest.

Starte jetzt mehrere von beiden Threads und schau, ob da etwas knallt. Dann hat man auch einen Erfahrungswert und wird noch viel ruhiger

In Richtung Multiplatform betrachtet ... benutzte einfach die neuen Interlocked-Funktionen aus der System-Unit.

Die aus der Windows-Unit kann man bekanntlich nicht überall benutzen.
Aus irgendeinem unerfindlichem Grunde mach der Mac die WinAPIs nicht.

Zitat von Sir Rufo:

Einen zusammengestückelten Wert wie 2 Bytes vom alten und 2 Bytes vom neuen Wert gibt es nicht.

Ausnahme wo einfaches Lesen/Schreiben auch mit "simplen" Typen wie Integer knallt ist in wenn dieser in einem packed record steckt.

Außerdem willst du eines Tages vielleicht doch mit mehreren Threads den Wert beschreiben und freust dich dann dass es direkt ohne Anlauf möglich ist. Ich würde einfach TInterLocked oder sonst was verwenden und glücklich sein.

Zitat von Der schöne Günther:

Zitat von Sir Rufo:

Einen zusammengestückelten Wert wie 2 Bytes vom alten und 2 Bytes vom neuen Wert gibt es nicht.

Ausnahme wo einfaches Lesen/Schreiben auch mit "simplen" Typen wie Integer knallt ist in wenn dieser in einem packed record steckt.

Das habe ich doch auch implizit erläutert ...

Zitat von Der schöne Günther:

Außerdem willst du eines Tages vielleicht doch mit mehreren Threads den Wert beschreiben und freust dich dann dass es direkt ohne Anlauf möglich ist. Ich würde einfach TInterLocked oder sonst was verwenden und glücklich sein.

Nene die Felder sind in normalen Klassen. Fehlt bei den Interlocked Implementationen von Delphi btw. die 16 Bit Variante oder bin ich blind?

Zu den packed records. Sowas würde also nicht funktionieren? Verstehe ich jetzt nicht ganz ..

markieren

Delphi-Quellcode:

type
  TRec = packed record
    A: Integer;
  end;

..

Rec.A := 100;

Außer des Alignments (was beim ersten Element hier in dem Beispiel natürlich egal wäre), ändert das "packed" Attribut doch eigentlich nichts an der ganzen Geschichte.

Zitat von Zacherl:

Zu den packed records. Sowas würde also nicht funktionieren? Verstehe ich jetzt nicht ganz ..

markieren

Delphi-Quellcode:

type
  TRec = packed record
    A: Integer;
  end;

..

Rec.A := 100;

Außer des Alignments (was beim ersten Element hier in dem Beispiel natürlich egal wäre), ändert das "packed" Attribut doch eigentlich nichts an der ganzen Geschichte.

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.

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.

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;