2016-08-01 24 views
1

Ich habe eine Datenstruktur, die nicht thread-save ist. Mehrere Threads lesen und schreiben diese Datenstruktur in 2 Methoden. (Die Reihenfolge der Anrufe ist eher zufällig) Mein Ansatz für dieses Problem einer unique_lock wurde mit wie unten dargestellt:C++ Sperre über Methoden

struct test { 

    void func1() { 
    boost::unique_lock<boost::mutex> lock(_mutex); 
    // modify data-structure 
    } 


    void func2() { 
    boost::unique_lock<boost::mutex> lock(_mutex); 
    // modify data-structure 
    } 

    boost::mutex _mutex; 
} 

ich aber, dass mit diesem Code, nur ein Thread zu einem Zeitpunkt erlaubt ist, auf die Daten zuzugreifen, Da der Mutex über die beiden Methoden geteilt wird.
Aber irgendwie kann Programm löst einen Fehler in der Datenstruktur, welche ich nicht in der Lage bin in meinem Single-Threaded-Testfälle zu reproduzieren ...

Habe ich die boost :: unique_lock in beiden Methoden verwenden müssen und dann anrufen

lock() 
unlock() 

drauf?

+0

Verwenden Sie stattdessen ['boost :: scoped_lock'] (http://www.boost.org/doc/libs/1_61_0/doc/html/boost/interprocess/scoped_lock.html). –

+2

Sie können auch 'std :: mutex' und' std :: lock_guard' für diesen Fall verwenden. Es gibt keine Notwendigkeit, Boost für alles zu verwenden, was in STL ist. – alexeykuzmin0

+0

@JoachimPileborg Warum macht es einen Unterschied in diesem Fall? Ein 'scoped_lock' sollte durch einen' unique_lock' ersetzt werden können. – Jens

Antwort

0

Der Sperrmechanismus, wie beschrieben, war nicht der Grund für den Fehler.
Nun, es war tatsächlich,)
Außerhalb des kritischen Abschnitts i

genannt
datastructure.empty() 

weil in einer früheren Version dieses Verfahren war Thread.

Dank "Kerrek SB" für das Zeigen auf Thread-Sanitizer, wie es mich Ausgang zum Fehler geführt hat.