3. Threads Synchronisieren auch bei Lese-Zugriff?

Threads Synchronisieren auch bei Lese-Zugriff?

  • 3

    Ich wollte damit sagen, dass in C++ nichts von Standard verlangt wird, um Thread-Safety zu garantieren. Das ist eben das C++-Prinzip: Wenn ich nicht mehrere Threads brauche, dann habe ich auch keinen Performancenachteil.

    0
  • ?

    Ok, würde mich freuen, wenn noch jemand das mit der sequentiellen konsistenz kommentieren kann.
    Also folgende Sachen:
    - Hab ich das richtig verstanden (siehe letzte Seite)
    - Warum wird sowas bei C++ garantiert, wenn das nichtmal bei java der fall ist?
    - Wirkt sich das nicht stark negativ auf die performance aus, oder können die compiler irgendwie rausfinden (stichwort escape analyse und co) was genau gemeinsam verwendet wird und dann nur dafür die flushs einfügen?

    0

  • Gast1337 schrieb:

    Aber nochmal zu den garantien bei C++:
    Ich hab gelesen, dass C++ sequentielle Konsistenz garantiert.

    The C++0x draft ensures sequential consistency for programs that do not explicitly specify weaker memory ordering constraints, which avoids data races (concurrent non-read-only accesses to the same memory location).

    Quelle: http://en.wikipedia.org/wiki/C%2B%2B0x#Multitasking_memory_model
    Das bedeutet, so wie ich das verstehe , dass es niemals sichbarkeitsprobleme geben kann, also das bei jedem schreibzugriff, der von einem anderen thread gelesen werden könnte ein memory flush ausgeführt wird und bei jedem lesezugriff sofern eine änderung durch einen anderen thread möglich war ein memory refresh ausgeführt wird.

    Ich hab den aktuellen Draft nicht gelesen, aber nach dem was ich in den letzten Monaten so mitbekommen habe gilt das nur für atomic<T> Variablen (bzw. für die diversen atomic_xxx Funktionen).
    Ähnliche war es auch eine Zeit lang für volatile Variablen geplant (bzw. im Gespräch), aber letztens hat man mich hier im Forum darauf hingewiesen dass es für volatile nicht in den Draft übernommen wurde.

    Für sämtliche Speicherzugriffe wäre es auch komplett plem, da es auf einigen Plattformen (CPUs) jedes C++ Programm auf Schneckentempo verlangsamen würde.

    0

  • 314159265358979 schrieb:

    Ich wollte damit sagen, dass in C++ nichts von Standard verlangt wird, um Thread-Safety zu garantieren. Das ist eben das C++-Prinzip: Wenn ich nicht mehrere Threads brauche, dann habe ich auch keinen Performancenachteil.

    Das stimmt so nicht ganz.

    Im neuen Standard wird für viele Funktionen threads-safety vorgeschrieben sein.
    Vermutlich für so ziemlich alle globalen Funktionen. Also z.B. auch ::operator new und ::operator delete.

    Da eine Heap-Implementierung nicht gratis thread safe gemacht werden kann, zahlt man bei Programmen ohne Threads also sehrwohl dafür, obwohl man es nicht verwendet.

    Das ist eben das C++-Prinzip

    Ja, C++ versucht dieses Prinzip umzusetzen, schafft es aber an vielen Stellen nicht.

    0
  • 3

    Wider was dazu gelernt 🙂

    0
  • X

    hustbaer schrieb:

    Im neuen Standard wird für viele Funktionen threads-safety vorgeschrieben sein.
    Vermutlich für so ziemlich alle globalen Funktionen. Also z.B. auch ::operator new und ::operator delete.

    Da eine Heap-Implementierung nicht gratis thread safe gemacht werden kann, zahlt man bei Programmen ohne Threads also sehrwohl dafür, obwohl man es nicht verwendet.

    Verstehe ich es richtig, dass in Nicht-Multi-Threading-Programmen eine (unnötige) Synchronisierung beim Anfordern von Speicher gemacht wird?
    Ich hätte eigentlich erwartet, dass bei der Übergabe des Parameters pthread erst Threadsicherheit in die Speicheranforderung (und andere Funktionen) integriert wird... 😮
    Klar ist es wahrscheinlich Compiler-abhängig, aber bei guten Compilern würde ich es leichtsinnigerweise(?) annehmen

    EDIT: Ganze Seiten müssen natürlich beim OS angefragt werden, die dann natürlich wegen anderen Prozessen synchronisiert werden müssen.

    0

  • Es ist möglich, dass der neue Standard es erlauben wird, dass die thread-safety der Standard-Library "opt out" ist. "opt in" halte ich für ganz verkehrt, und ich hoffe dass der neue Standard das auch nicht erlauben wird.

    Wie es bei GCC und Linux ist kann ich nicht sicher sagen. Ich schätze dass da auch per Default alles thread-safe. Was MSVC angeht: ab VS 2010 gibt es keine single-threaded Runtime mehr.

    ps:

    Verstehe ich es richtig, dass in Nicht-Multi-Threading-Programmen eine (unnötige) Synchronisierung beim Anfordern von Speicher gemacht wird?

    Sobald die Runtime als DLL oder SO vorliegt, kann man nicht mehr so einfach sagen ob das Synchronisieren unnötig ist oder nicht. Angenommen du verwendest Library X, und Library X verwendet intern Threads (ohne dass du was davon mitbekommst). Und Library X ist gegen die selbe Runtime gelinkt. Dann muss synchronisiert werden. "Library X" kann dabei auch Teil des Betriebssystems sein. (Bei Windows weniger, da das OS nicht die Visual Studio Runtime verwendet, aber bei Linux ist es soweit ich weiss ganz normal dass "alles" (vieles) im System die selbe Runtime-Library, und damit auch den selben Heap verwendet)

    0
  • X

    hustbaer schrieb:

    Sobald die Runtime als DLL oder SO vorliegt, kann man nicht mehr so einfach sagen ob das Synchronisieren unnötig ist oder nicht.

    Stimmt 👍

    0
Anmelden zum Antworten