Die Verwendung von Sperren und Mutexen ist in harten Echtzeitrückrufen unzulässig. Lock-freie Variablen können in verschiedenen Threads gelesen und geschrieben werden. In C kann die Sprachdefinition gebrochen sein oder nicht, aber die meisten Compiler spenden brauchbaren Assemblercode aus, wenn eine Variable als flüchtig deklariert wird (der Leser-Thread behandelt die Variable als Hardwareregister und gibt somit Ladeanweisungen aus, bevor die Variable verwendet wird). was auf den meisten cache-kohärenten Multiprozessorsystemen gut genug funktioniert.)
Kann diese Art des variablen Zugriffs in Swift angegeben werden? Oder müssen Inline-Assembler oder Datencache-Flush / Invalidate-Hinweise stattdessen zur Swift-Sprache hinzugefügt werden?
Hinzugefügt: Wird die Verwendung von Aufrufen von OSMemoryBarrier () (von OSAtomic.h) vor und nach und jede Verwendung oder Aktualisierung von möglicherweise inter-thread Variablen (wie "Lock-free" Fifo / Puffer-Statuszähler, etc.) .) in Swift erzwingen ausreichend geordneten Speicher laden und speichern Anweisungen (auch auf ARM-Prozessoren)?
Wie Sie bereits erwähnt haben, garantiert volatile
nur, dass die Variable nicht zwischengespeichert wird (wird selbst als Register behandelt). Das allein macht es nicht frei für Lese- und Schreibvorgänge. Es garantiert nicht einmal seine Atomarität, zumindest nicht in einer konsistenten, plattformübergreifenden Art und Weise.
Warum? Es fällt mir zum erstens das Befehlspipelining und das Überdimensionieren (z. B. Verwenden von Float64 auf einer Plattform mit 32 Bit oder weniger Gleitkommaregistern) in den Sinn.
Haben Sie darüber nachgedacht, OSAtomic zu verwenden?
Tags und Links swift