kann ein geteilter Puffer threadsicher mit std :: atomic flags sein? Gibt es einen effizienteren Weg dies zu tun?

Question

Hallo SO! Gibt es bei jeder Änderung eine Möglichkeit, dass der "wartende Thread" den "Buff" nicht aktualisiert bekommt? sollte ich einen lock_guard in den thread einfügen, der den "buff" ändert? Ich habe über Speicher Zäune auf einige Artikel gelesen, wie diese: https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ und ich bin nur besorgt darüber. Vielen Dank im Voraus ...

#include <iostream> 
#include <thread> 
#include <chrono> 
#include <atomic> 

int main(){ 
    std::atomic<bool> ready(false); 
    char buff[20]= "hello"; 

    std::cout << "creating thread to change \"buff\"..." << std::endl; 
    std::thread tr(
     [ & ready, & buff ](){ 
      std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
      //should i put a lock_guard here? 
      buff[0]= 'w'; buff[1]= 'o'; 
      buff[2]= 'r'; buff[3]= 'l'; 
      buff[4]= 'd'; buff[5]= '\0'; 
      std::cout << "buffer changed! sending signal to waiting thread..." << std::endl; 
      ready= true; 
    }); 

    tr.detach(); 
    std::cout << "...waiting for the change..." << std::endl; 
    while(!ready); 

    std::cout << "...got it! buff=" << buff << std::endl; 
} 

Answer 1

Weil Sie nicht die Speicher Sichtbarkeit Semantik für Ihre Zuordnung zu ready angegeben haben, können Sie die Standard-Semantik erhalten. Welche sind:

Das Standardverhalten aller atomaren Operationen in der Bibliothek sorgt für sequenziell konsistente Reihenfolge (siehe unten). - std::memory_order

So erhalten Sie "sequenziell konsistente Bestellung". Nun, was zum Teufel ist das?

Jede Operation mit dieser Speicherreihenfolge ist sowohl eine Erfassungsoperation als auch eine Freigabeoperation. Außerdem existiert eine einzige Gesamtbestellung, in der alle Threads alle Änderungen (siehe unten) in derselben Reihenfolge beobachten.

Das klingt gut. Aber was ist eine "Freigabeoperation"?

Ein Speichervorgang mit dieser Speicherreihenfolge führt den Freigabevorgang aus: Nach diesem Speicher können keine Speicherzugriffe im aktuellen Thread neu angeordnet werden. Dies stellt sicher, dass alle Schreibvorgänge in dem aktuellen Thread in anderen Threads sichtbar sind, die die gleiche atomare Variable erhalten, und Schreibvorgänge, die eine Abhängigkeit in die atomare Variable tragen, werden in anderen Threads sichtbar, die denselben atomaren Datentyp verwenden.

So bedeutet das, dass jeder Thread, der die Änderung ready sieht, wird es keine schreibt, bevor es getan sehen, welche die, die zu buff enthält. Daher ist dieser Teil Ihres Codes in Ordnung, soweit Datenrennen gehen. (Es ist schrecklich für viele andere Gründe, natürlich.)

Answer 2

Basierend auf den Empfehlungen von David Schwartz und Igor Tandetnik, ich den Code geändert Bedingungsvariablen zu verwenden, und den Faden zu lösen:

#include <iostream> 
#include <thread> 
#include <chrono> 
#include <condition_variable> 

int main(){ 
    std::mutex mutex_condition; 
    std::condition_variable condition; 
    bool ready= false; 
    char buff[20]= "hello"; 

    std::cout << "creating thread to change \"buff\"..." << std::endl; 
    std::thread tr(
     [ & condition, & mutex_condition, & ready, & buff ](){ 
      { 
       std::lock_guard<std::mutex> lock_(mutex_condition); 
       std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
       buff[0]= 'w'; buff[1]= 'o'; 
       buff[2]= 'r'; buff[3]= 'l'; 
       buff[4]= 'd'; buff[5]= '\0'; 
       std::cout << "buffer changed! sending signal to waiting thread..." << std::endl; 
       ready= true; 
      } 
      condition.notify_one(); 
    }); 

    std::cout << "...calling detach..." << std::endl; 
    tr.detach(); 

    std::cout << "...waiting for the change..." << std::endl; 
    std::unique_lock<std::mutex> lock_(mutex_condition); 
    condition.wait(lock_, [ & ready ]{ return ready; }); 

    std::cout << "...got it! buff=" << buff << std::endl; 
} 

Thank you! Hoffentlich könnte das jemand anderem helfen.