Kopierkonstruktor und Threads



  • Hallo,

    in einer Multithreadanwendung habe ich für eine meiner Klassen einen Kopierkonstruktor vorgesehen. Mein Vorgehen ist immer so, daß ich die Member
    in der Initialisierliste bestücke. Als Beispiel mal folgende Signatur:
    'meinklasse::meineklasse( const meineklasse &other)'. Die Klasse hat auch einen Lockmember. Nun wäre es doch möglich, das in der Zeit in der ich im Kopierkonstruktor die Member von 'other' auslese ein anderer Thread 'other' manipuliert. Besser wäre es doch dann die 'get'-Methoden zu benutzen oder was meint Ihr? Kleines Beispiel:

    // normalweweise:
    meinklasse::meineklasse( const meineklasse &other)
    :memberA(other.memberA),
     memberB(other.memberB)
    {
    }
    
    // mit Threads
    meinklasse::meineklasse( const meineklasse &other)
    :memberA(other.getA()),
     memberB(other.getB())
    {
    }
    

    Die 'get'-Methoden sind dann natürlich synchronisiert.
    Vielen Dank im voraus.

    leftshift



  • Der Clientcode (die aufrufende Funktion im selben Thread) wollte ja eine Kopie des Objekts zu dem Zeitpunkt des Aufrufs erstellen und ihm sollte auch bewusst sein, dass andere Threads dieses Objekt ebenfalls verwenden. Ich denke es sollte dem Client-Code obliegen, das Objekt zu locken, bevor er damit etwas anstellt.



  • Da hast Du auch wieder recht. 👍



  • Decimad schrieb:

    Der Clientcode (die aufrufende Funktion im selben Thread) wollte ja eine Kopie des Objekts zu dem Zeitpunkt des Aufrufs erstellen und ihm sollte auch bewusst sein, dass andere Threads dieses Objekt ebenfalls verwenden. Ich denke es sollte dem Client-Code obliegen, das Objekt zu locken, bevor er damit etwas anstellt.

    Grundsätzlich ja.

    Bloss ... sobald eine Klasse eine eingebaute Mutex hat, um "sich selbst" threadsafe zu machen, erwarte ich auch, dass alle Operationen threadsafe sind.

    Also entweder Mutex raus aus der Klasse, oder Copy-Ctor synchronisieren.
    Dann aber bitte nicht mittels get-Funktionen, denn auf die Art könnte sich zwischen den Aufrufen zweier Getter nochmal was ändern. Dann hättest du einen inkonsistenten Zustand kopiert.

    Also lieber nix in der initializer-list machen, dann im Ctor-Rumpf die innere Mutex locken, und alle Member rüberkopieren.



  • Tja multithreading ist halt immer so eine Sache. Ich werde mir die Klasse nochmals genau anschauen ob sich der Lock innerhalb der Klasse überhaupt 'rechnet'. Zu feingranular sollte Locking ja auch wieder nicht sein.
    Vielen Dank für die Antworten.

    leftshift


Anmelden zum Antworten