Shared-memory IPC-Synchronisation (lock-frei)

Betrachten Sie das folgende Szenario:

Anforderungen:

  • Intel x64 Server (mehrere CPU-sockel => NUMA)
  • Ubuntu 12, GCC 4.6
  • Zwei Prozesse, welche große Mengen von Daten über (benannte) shared-memory -
  • Klassischen Erzeuger-Verbraucher-Szenario
  • Speicher angeordnet ist, in einen Ringspeicher (mit M Elementen)

Programm-Sequenz (pseudo-code):

Prozess Ein (Hersteller):

int bufferPos = 0;
while( true )
{
    if( isBufferEmpty( bufferPos ) )
    {
        writeData( bufferPos );
        setBufferFull( bufferPos );

        bufferPos = ( bufferPos + 1 ) % M;
    }
}

Prozess B (Verbraucher):

int bufferPos = 0;
while( true )
{
    if( isBufferFull( bufferPos ) )
    {
        readData( bufferPos );
        setBufferEmpty( bufferPos );

        bufferPos = ( bufferPos + 1 ) % M;
    }
}

Nun die uralte Frage: Wie synchronisieren Sie Sie effektiv!?

  1. Schützen jeder lese - /schreib-Zugriff mit Mutexe
  2. Die Einführung einer "Karenzzeit", um zu erlauben, schreibt abschließen: Lesen der Daten im Puffer N, wenn Puffer(N+3) markiert wurde, wie die volle (gefährlich, aber scheint zu funktionieren...)
  3. ?!?

Idealerweise würde ich gerne etwas entlang der Linien von einer memory-Barriere, die gewährleistet, dass alle vorherigen liest/schreibt, sind sichtbar über alle CPUs, entlang der Linien von:

writeData( i );
MemoryBarrier();

//All data written and visible, set flag
setBufferFull( i );

So, ich würde nur beobachten, wie sich die buffer-flags und dann Lesen konnte, die große Daten-chunks sicher.

Generell bin ich auf der Suche nach etwas entlang der Linien von " acquire/release Zäune, wie beschrieben, durch Preshing hier:

http://preshing.com/20130922/acquire-and-release-fences/

(wenn ich es richtig verstehe, die C++11 atomics funktionieren nur für die threads eines einzelnen Prozesses und nicht über mehrere Prozesse.)

Jedoch die GCC-eigenen memory-Barrieren (__sync_synchronize in Kombination mit den compiler-Barriere asm volatile( "" ::: "memory" ), um sicher zu sein) scheinen nicht wie erwartet funktionieren, so schreibt sichtbar werden, nachdem die Barriere, wenn ich erwartet, dass Sie abgeschlossen sein.

Jede Hilfe würde geschätzt...

BTW: Unter windows-das funktioniert gut mit volatile-Variablen (eine Microsoft-spezifische Verhalten)...

InformationsquelleAutor Ben | 2014-03-05
  1. 26

    Boost Prozessübergreifende Unterstützung für den Gemeinsamen Speicher.

    Boost-Lockfree ist ein Single-Produzent Single-Verbraucher queue-Typ (spsc_queue). Dies ist im Grunde, was Sie sich beziehen, als ein Ringpuffer.

    Hier ist eine demonstration, der vergeht, IPC-Nachrichten (in diesem Fall der Typ string) mit dieser Warteschlange, die in einen lock-free Mode.

    Die Festlegung der Arten

    Zunächst definieren wir unsere Typen:

    namespace bip = boost::interprocess;
namespace shm
{
    template <typename T>
        using alloc = bip::allocator<T, bip::managed_shared_memory::segment_manager>;

    using char_alloc    =  alloc<char>;
    using shared_string =  bip::basic_string<char, std::char_traits<char>, char_alloc >;
    using string_alloc  =  alloc<shared_string>;

    using ring_buffer = boost::lockfree::spsc_queue<
        shared_string, 
        boost::lockfree::capacity<200> 
        //alternatively, pass
        //boost::lockfree::allocator<string_alloc>
    >;
}

    Einfachheit halber wählte ich, um die demo-Laufzeit-Größe spsc_queue Umsetzung, zufällig anfordern einer Kapazität von 200 Elementen.

    Den shared_string typedef definiert einen string, transparent-Zuweisung aus dem shared memory segment, so dass Sie auch "magisch" gemeinsam mit den anderen Verfahren.

    Die consumer-Seite

    Dies ist die einfachste, also:

    int main()
{
    //create segment and corresponding allocator
    bip::managed_shared_memory segment(bip::open_or_create, "MySharedMemory", 65536);
    shm::string_alloc char_alloc(segment.get_segment_manager());

    shm::ring_buffer *queue = segment.find_or_construct<shm::ring_buffer>("queue")();

    Dieser öffnet die shared-memory-Bereich, sucht der shared queue, wenn vorhanden. HINWEIS Diese synchronisiert werden sollen, im realen Leben.

    Nun für die eigentliche demonstration:

    while (true)
{
    std::this_thread::sleep_for(std::chrono::milliseconds(10));

    shm::shared_string v(char_alloc);
    if (queue->pop(v))
        std::cout << "Processed: '" << v << "'\n";
}

    Den Verbraucher nur unendlich überwacht die Warteschlange für ausstehende Aufträge und Prozesse jeweils ~10ms.

    Die Hersteller Seite

    Der Hersteller-Seite ist sehr ähnlich:

    int main()
{
    bip::managed_shared_memory segment(bip::open_or_create, "MySharedMemory", 65536);
    shm::char_alloc char_alloc(segment.get_segment_manager());

    shm::ring_buffer *queue = segment.find_or_construct<shm::ring_buffer>("queue")();

    Wieder, fügen Sie die richtige Synchronisierung der Initialisierungsphase. Auch, Sie wären wahrscheinlich der Produzent verantwortlich für die Befreiung der shared-memory-segment zu gegebener Zeit. In dieser demonstration habe ich einfach "lass ihn hängen". Das ist ganz nett zum testen, siehe unten.

    So, was hat der Hersteller tun?

        for (const char* s : { "hello world", "the answer is 42", "where is your towel" })
    {
        std::this_thread::sleep_for(std::chrono::milliseconds(250));
        queue->push({s, char_alloc});
    }
}

    Recht, der Produzent produziert genau 3 Nachrichten in ~750ms und wird dann beendet.

    Beachten Sie, dass folglich, wenn wir das tun (unter der Annahme einer POSIX-shell mit job-Kontrolle):

    ./producer& ./producer& ./producer&
wait

./consumer&

    Drucken 3x3-Nachrichten "sofort", während die Verbraucher ausgeführt. Dabei

    ./producer& ./producer& ./producer&

    wieder nach diesem, zeigen die Nachrichten "einsickern" in Echtzeit (im burst von 3 auf ~250ms Intervallen), weil der Verbraucher ist immer noch im hintergrund laufen

    Finden Sie den vollständigen code online in diesem gist: https://gist.github.com/sehe/9376856

    • Gerade bemerkt, gcc 4.6 erwähnt. Es ist möglich, dass diese version nicht über einheitliche inializers. Nur der explizite Aufruf des Konstruktors für shared_string dann, wenn er in die Warteschlange.
    • Danke für deine ausführliche Antwort. Es ist immer wieder faszinierend zu sehen, wie auch komplexe Probleme kommen bis zu 100 Zeilen code im boost 😉 Aber meine Frage bleibt immer noch. Gibt es ein Konstrukt, erzwingt Speicher Sichtbarkeit (etwas ähnliches wie smp_mb(), dass ist nur der kernel)). Oder in anderen Worten, wie Mutexe durchzusetzen Speicher Sichtbarkeit?
    • Es ist 54 Zeilen code (ohne makefile). Ich habe gerade geschoben ein c++03-update auf das wesentliche. Die Lockfree-Bibliothek verwendet atomics in der zugrunde liegenden Implementierung, so glaube ich, zu beschäftigen, die richtigen Hindernisse. Ich wäre überrascht, wenn die Tatsache, dass Speicher-Seiten geteilt werden, hat keine Auswirkungen auf die Sichtbarkeit der Semantik. Hier sind einige Notizen über die Prozessübergreifende Unterstützung im Boost-Lockfree-Dokumentation
    • Wenn Sie schauen, für ein gemeinsames mutex (named mutex Win32) finden Sie unter Mutex oder synchronisationsmechanismen im überblick in der Boost-Interprozess-docs.
    • Ok, danke nochmal für deine Antwort. Ich habe einen Blick in die boost-Interprozesskommunikation und atomics Quellen und nur gestoßen "vertraut" Barriere-Implementierungen. Also ich verstehe immer noch nicht, warum der memory-Barriere (__sync_synchronize) funktioniert nicht wie erwartet in meiner Implementierung. Jedoch, wie dies geht über meine ursprüngliche Frage, ich werde markieren Sie Ihre (gute) Antwort als akzeptiert 🙂
    InformationsquelleAutor sehe
Schreibe einen Kommentar