boost :: mutex :: ~ mutex (): Die Assertion '! pthread_mutex_destroy (& m)' ist fehlgeschlagen

8

Ich habe den Unterschriftsfehler im Mutex-Destruktor erhalten. Da der Fehler aufgrund des Mutex während der Zerstörung im Sperrzustand sein kann, erstelle ich eine neue Mutex-Klasse, die von boost: mutex geerbt wird. Es ist sicherzustellen, dass der Mutex während der Zerstörung entsperrt wird. Derselbe Fehler tritt jedoch weiterhin auf. Jeder Treffer wäre willkommen!

%Vor%

BEARBEITEN: Ja, du hast recht. Ich sollte RAII verwenden. Ich bin jedoch in einer Situation. Ich muss eine Ressource sperren, bevor ein anderer Thread die Verarbeitung beendet. etwas wie unten.

%Vor%     
Michael D 19.10.2011, 06:01
quelle

3 Antworten

7

Nicht erbt von boost::mutex , die Klasse boost::mutex hat keinen virtuellen Destruktor, daher ist sie nicht für die Vererbung gedacht.

Mögliche Ursache:
Der Fehler, den Sie erhalten, zeigt an, dass Sie unlock für einen Mutex aufrufen, der nie gesperrt wurde. Etwas wie:

%Vor%

Wenn Sie lock und unlock versuchen, scheint es, als würden Sie die Spur verlieren, ob der Mutex gesperrt ist. Dies ist häufig das Problem, wenn Sie die Ressourcenverwaltung manuell durchführen. C ++ erlaubt einen spezifischen Mechanismus, der Resource Allocation is Initiilization ( RAII) zum Schutz vor solchen Problemen.

Vorgeschlagene Lösung:
Sie sollten RAII verwenden, statt den Mutex explizit zu entsperren. Sie könnten den boost :: mutex :: scoped_lock verwenden, um RAII zu implementieren:

%Vor%     
Alok Save 19.10.2011, 06:11
quelle
3

Ich hatte den gleichen Fehler (so habe ich diese Frage gefunden). Ich habe nach Problem gelöst, indem ich einen join zum relevanten Thread hinzufüge. Mein Hauptprozess war beendet, bevor der Thread es getan hat und der mutex wurde abgerissen, bevor er freigeschaltet werden konnte.

    
tacaswell 11.09.2012 06:56
quelle
2

POSIX gibt an, dass die einzigen Fehler, die von einer Operation pthread_mutex_destroy zurückgegeben werden, EINVAL sind, wenn der Mutex irgendwie ungültig ist, oder EBUSY , wenn jemand sie verwendet (explizit oder über Zustandsvariablen).

Das wahrscheinlichste Szenario ist das zweite.

Ich sehe jedoch keine Änderungen an der m_bLock -Membervariable in Ihrem Code. Sind Sie sicher, dass Sie diese Variable nicht in den Aufrufen lock und unlock ändern möchten?

Wenn verwendet wird, müssen Sie nur warten, bis derjenige, der es verwendet, bereit ist, es freizugeben. Jede andere Option ist wahrscheinlich nicht gut für Sie: -)

    
paxdiablo 19.10.2011 06:12
quelle

Tags und Links