Kann die Hardware eine Atomlast nachordnen, gefolgt von einem Atomgeschäft, wenn das Geschäft von der Last abhängig ist? ⇐ C++

[Anonymous]

Kann die Hardware eine Atomlast nachordnen, gefolgt von einem Atomgeschäft, wenn das Geschäft von der Last abhängig ist? Es wäre sehr unintuitiv, wenn dies passieren könnte, denn wenn Thread1 spekulativ aufgrund von Zweigvorhersage oder aus irgendeinem Grund y = 1 vor der Bedingung in der IF -Anweisung als True schreibt. /> Ich glaube nicht, dass die Veröffentlichung und Erwerb von Semantik für diesen Fall helfen wird. Ein std :: memory_order_release auf y.store () wird verwendet, um frühere Schreibvorgänge für andere Threads sichtbar zu machen, die den Wert von y sehen, aber in diesem Fall gibt es nichts, was Thread1 zur Auswirkungen der Sichtbarkeit von x auf anderen Threads tun kann, weil X nicht von Thread1 geschrieben wurde. Die Beispiele, die ich in der C ++-Dokumentation zum Erwerb und zur Veröffentlichung von Semantik gesehen habe, sprechen nur über ein Threadpaar, bei dem einer rein ein Schriftsteller ist und der andere nur ein Leser ist.

Code: Select all

std::atomic x;
std::atomic y;

void thread1() {
int val = x.load(std::memory_order_relaxed);
if( val == 42 ){
y.store(1, std::memory_order_relaxed);
}
}
< /code>
Bearbeiten: Ich wurde gebeten, Beispiele einschließlich anderer Threads anzugeben. Bei einem der von Beobachtern wahrgenommenen Geschäften, während es beim anderen die Möglichkeit einer spekulativen Ausführung von Geschäften handelt. (Durch eine IF-Anweisung) zum Ergebnis der Last (dies ist, was Thread1 im Beispiel tut), erstellt die IF-Anweisung dann effektiv einen Zaun für Lastgeschäfte, was bedeutet, dass die Last abgeschlossen ist, bevor der Speicher für einen anderen Thread sichtbar werden kann (oder einer anderen Beobachtungseinheit wie einem direkten Speicherzugriffsgerät)? Gibt die IF-Anweisung in der C ++-Terminologie ein, vor dem Laden und der Last ein passiert? In der C ++ - Dokumentation über die Speicherbestellung wird in der C ++ - erwähnt nichts über bedingte Geschäfte. Im C ++-Formalismus wird ein passiert, bevor das Geschäft die Veröffentlichungsreihenfolge verwendet. Release-Ordering stoppt jedoch auch die Neuordnung des Store-Store-Ladens, sodass es strenger ist. Wenn meine Idee funktioniert und Sie nur eine Last-Store-Bestellung benötigen, kann die IF-Anweisung ohne explizite Speicherzäune effizienter sein als eine Store_Release. Ich glaube, es ist wahrscheinlich, dass dies immer auf echter Hardware funktioniert, aber die C ++-Dokumentation ist einfach unvollständig und bietet schwächere Garantien als nötig, sodass Verhaltensweisen, die in der realen Welt niemals auf realer Hardware geschehen können.// This example is about ordering.
// Will thread3 see the new value of x, if thread1 has seen it?
std::atomic x;
std::atomic y;

void thread1() {
int val = x.load(std::memory_order_relaxed);
if( val == 42 ){
y.store(1, std::memory_order_relaxed);
}
}

void thread2() {
x.store(42, std::memory_order_relaxed);
}

void thread3() {
if( y.load(std::memory_order_relaxed) == 1 ){
std::atomic_thread_fence(memory_order_acquire);
int r = x.load(std::memory_order_relaxed);
assert(r == 42); // Can this go wrong?
}
}
< /code>
// Similar, but we're putting it inside a loop
// to make it a little more interesting.
// This focuses on speculative execution.
std::atomic x;
std::atomic y;
std::atomic terminate;

void thread1() {
while( !terminate.load(std::memory_order_relaxed) ){

int val = x.load(std::memory_order_relaxed);
if( val == 42 ){
// Can y.store() be done speculatively?
y.store(1, std::memory_order_relaxed);
break;
}

}
}

void thread2() {
// This will count down and write to x,
// but should never actually store the value 42.
for(int idx = 10000000; idx > 42; --idx){
x.store(idx, std::memory_order_relaxed);
}
sleep_seconds(10);
terminate = true;
}

void thread3() {
while( !terminate.load(std::memory_order_relaxed) ){

if( y.load(std::memory_order_relaxed) == 1 ){
// This should never happen!
Open_Pandoras_Box();
Launch_Nuclear_Missiles();
Unleash_Armageddon();
break;
}

}
}