Ist es möglich, Speicherbarrieren nur auf der Speicherseite zu verwenden?

Zuerst einige Kontext: Ich arbeite mit einem Pre-C11, Inline-Asm-basierten atomaren Modell, aber für die Zwecke dieser bin ich glücklich zu ignorieren der C-Aspekt (und alle Compiler-Barriere Probleme, die ich separat behandeln kann) und betrachten es im Wesentlichen nur eine asm/CPU-Architektur Frage.Ist es möglich, Speicherbarrieren nur auf der Speicherseite zu verwenden?

Angenommen, ich habe Code, der wie folgt aussieht:

various stores 
barrier 
store flag 
barrier

Ich möchte in der Lage sein flag von einem anderen CPU-Kern zu lesen und zu dem Schluss, dass die various stores wurden bereits durchgeführt und sichtbar gemacht. Ist es möglich, dies zu tun ohne irgendeine Art von Speicher Barriere Anweisung auf der Ladeseite? Offensichtlich ist es zumindest bei einigen CPU-Architekturen möglich, zum Beispiel bei x86, wo eine explizite Speicherbarriere auf keinem der beiden Kerne benötigt wird. Aber wie sieht es überhaupt aus? Variiert es stark durch CPU-Bogen, ob dies möglich ist?

Quelle

2014-10-10 R..

AFAIK, Alpha benötigt Barrieren, während ARM/PPC entweder Barrieren oder Adress-/Datenabhängigkeiten oder RW-Steuerabhängigkeiten oder RR-Steuerabhängigkeiten + ISYNC/ISB zwischen dem Lesen des Flags und der davon abhängigen Operation benötigt. Für ARM/PPC könnten Sie an "Einführung in die ARM und POWER Relaxed Memory Modelle" interessiert sein. – ninjalj

Ein weiterer Datenpunkt: Gemäß dem Vorschlag zur Speicherbelegung unter http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1444.htm können einige eingebettete MIPS-CPUs auch Barrieren vermeiden, indem sie Abhängigkeiten verwenden (ältere, "wahre" MIPS sind angeblich seq-cst). Da 'smp_read_barrier_depends()' im Linux-Kernel nur eine Barriere für Alpha ist, scheint es, dass, wenn es eine (möglicherweise falsche) Adressabhängigkeit auf der Leseseite gibt, die Lesebarriere vermieden werden kann (außer Alpha). Den Compiler zu veranlassen, die Abhängigkeit beizubehalten, ist ein ganz anderes Problem. – ninjalj

Wenn eine CPU die Lasten neu anordnen würde, würde Ihr Code eine Lastschranke benötigen, um korrekt zu funktionieren. Es gibt viele Architekturen, die solche Nachbestellungen vornehmen; für einige Beispiele siehe die Tabelle in Memory ordering.

Daher erfordert Ihr Code im allgemeinen Fall Lastbarrieren.

x86 ist nicht sehr typisch, da es ziemlich strenge Speicherbestellgarantien bietet. Eine Diskussion finden Sie unter Who ordered memory fences on an x86?.

Quelle

2014-10-10 06:09:16 NPE

Ist es möglich, die Lasten neu zu ordnen, wenn eine der Lasten überhaupt auftritt, hängt von dem Wert ab, der von der anderen geladen wird? Sicherlich kann diese Art der Neuordnung nicht auf einer Compiler-Ebene stattfinden (weil sie fehlerbehaftete Lasten erzeugen könnte), aber vielleicht kann die CPU spekulativ Lasten ausführen, die möglicherweise fehlerhaft sind und den Fehler einfach aufschieben. –

Vielen Dank für den Link "Wer hat Speicher Zäune auf einem x86 bestellt". Sehr interessant gelesen - ich habe mich immer gewundert, warum, mit starken Bestellgarantien, bereits ein expliziter Zaunbefehl hinzugefügt wurde. –

Hier ist ein weiterer interessanter Vortrag, der Dinge erklären kann - http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-2-of-2 – Leeor

Ist es möglich, Speicherbarrieren nur auf der Speicherseite zu verwenden?

Antwort

Verwandte Themen