Boost atomic object



  • Hallo,

    ich habe eine Frage zu boost atomic objects. Laut boost doku

    http://www.boost.org/doc/libs/1_59_0/doc/html/atomic/interface.html#atomic.interface.interface_atomic_object

    steht hier

    boost::atomic<T> provides methods for atomically accessing variables of a suitable type T. The type is suitable if it is trivially copyable (3.9/9 [basic.types]). Following are examples of the types compatible with this requirement:

    • a scalar type (e.g. integer, boolean, enum or pointer type)
    • a class or struct that has no non-trivial copy or move constructors or assignment operators, has a trivial destructor, and that is comparable via memcmp.

    Note that classes with virtual functions or virtual base classes do not satisfy the requirements. Also be warned that structures with "padding" between data members may compare non-equal via memcmp even though all members are equal.

    Ich verstehe 2 Dinge nicht:

    1. den zweiten punkt nicht, was ist "a class/struct that has no non-trivial copy or move constructors..." ?

    2. UNd as hier auch nicht: "also be warned that structures with "padding" ..."

    Kann mir jemand das irgendwie einfacher erklären?

    Danke


  • Mod

    1. Klassen, die keinen selbstgeschriebenen Konstruktoren oder Destruktoren haben (inklusive aller Member und Basisklassen, für die das gleiche gelten muss).

    2. Wenn man eine Klasse definiert, steht nur fest, in welcher Reihenfolge die Membervariablen letztlich im Speicher liegen werden, aber es steht nicht die genaue Position fest. Insbesondere ist es möglich, dass zwischen Membern Platz gelassen wird, da es effizienter ist, wenn eine Variable an einem vielfachen bestimmter Adressen (meistens 4 oder 😎 steht. Das heißt, in dem Fall würden dann Füllbytes (Padding) in dem Objekt vorliegen, deren Werte undefiniert sind.



  • Danke schonmal.

    Bzgl. 1) Was passiert wenn ich als T etwas verwende das 1 der beiden punkte verletzt? Ist der Zugriff nicht mehr atomar (also teilbar und damit nicht mehr race-sicher wenn mehrere threads "gleichzeitig" zugreifen) oder wird dann jeglicher Zugriff über ein lock emuliert um wenigstens den Zugriff thread-sicher zu gestalten?

    Bzgl. 2) Wie stelle ich dann sicher dass kein padding hergestellt wird und ich einen Typ habe der atomarem Zugriff erlaubt? So wüsste ich ja nie ob gepadded wird oder nicht...



  • 2.) Dazu gibt es Anweisungen die spezifisch für jeden Kompiler sind. Beispielsweise gibt es für den Microsoft Compiler #pragma pack (..) , siehe hier: https://msdn.microsoft.com/en-us/library/2e70t5y1.aspx - für den GCC gibt es selbstverständlich etwas gleichwertiges.


  • Mod

    Bezüglich 1: Kommt drauf an, was boost genau damit macht. Entweder gibt es einen Fehler beim compilieren, oder es gibt einen Fehler zur Laufzeit. Ersteres passiert, falls Boost irgendwelche Tests macht oder besondere Sprachfeatures nutzt, die nur unter den vorgegebenen Bedingungen existieren; letzteres passiert, falls Boost sich einfach blind darauf verlässt, dass die Bedingungen erfüllt sind. Das von dir beschriebene Szenario wird sicherlich nie auftauchen.

    Du scheinst etwas merkwürdige Vorstellungen zu haben, was die Bibliothek überhaupt macht. Es geht doch gerade darum, dass für Datentypen, bei denen der Zugriff nicht atomar in der Hardware erfolgt (bei denen also eigentlich gar nicht nötig ist, irgendetwas zu tun), stattdessen durch irgendwelche Locking-Mechanismen sicher gestellt wird, dass sie sich so verhalten, als ob der Zugriff atomar wäre.


Anmelden zum Antworten