2011-10-19 31 views
8

मुझे mutex विनाशक में कैप्शन त्रुटि मिली। चूंकि त्रुटि म्यूटेक्स के कारण विनाश के दौरान लॉक स्थिति में हो सकती है, इसलिए मैं एक नया म्यूटेक्स वर्ग बनाता हूं जिसे बढ़ावा से विरासत में मिला है: mutex। यह सुनिश्चित करना है कि म्यूटेक्स विनाश के दौरान अनलॉक है। हालांकि, वही त्रुटि अभी भी होती है। किसी भी हिट की सराहना की जाएगी!boost :: mutex :: ~ mutex(): Assertion `! Pthread_mutex_destroy (& m) 'असफल

class CMutes : public boost::mutex 
{ 
public: 
    CMutes() 
    { 

    }; 

    virtual ~CMutes() 
    { 
     if (m_bLock) 
      boost::mutex::unlock(); 
    }; 

    void lock() 
    { 
     if(!m_bLock) 
      boost::mutex::lock(); 
     else 
      cout << "Mutex is in lock state\n"; 
    }; 

    void unlock() 
    { 
     if (m_bLock) 
      boost::mutex::unlock(); 
     else 
      cout << "Mutex is in unlock state\n"; 
    } 

    boost::mutex& getMutex() 
    { 
     return *this; 
    } 

private: 

    bool m_bLock; 
}; 

संपादित करें: हाँ आप सही हैं। मुझे आरएआईआई का उपयोग करना चाहिए। हालांकि, मैं एक स्थिति में हूं। किसी अन्य थ्रेड को संसाधित करने से पहले मुझे संसाधन लॉक करने की आवश्यकता है। नीचे की तरह कुछ।

Thread A: 
void getDate() 
{ 
m_oLock.lock(); 
// access resource 
} 

void unlock() 
{ 
m_oLock.unlock(); 
} 
Thread B: 
void Process() 
{ 
threadA.getData(); 
threadA.unlock(); 
} 

उत्तर

7

boost::mutex से नहीं इनहेरिट करते हैं, boost::mutex वर्ग, एक आभासी नाशक नहीं है तो यह वास्तव में विरासत के लिए नहीं है।

संभावित मूल कारण:
त्रुटि आप हो रही है इंगित करता है कि आप एक म्युटेक्स कि कभी नहीं ताला लगा हुआ था पर unlock बुला रहे हैं। की तरह कुछ:

boost::mutex m; 
m.unlock(); 

lock और unlock करने का प्रयास कर करके, ऐसा लगता है कि आप में से है कि क्या locked.This रूप म्युटेक्स बहुत बार समस्या यह है कि जब आप संसाधन प्रबंधन मैन्युअल रूप से प्रदर्शन पर नज़र रखें। सी ++ ऐसी समस्याओं के खिलाफ सुरक्षित सुरक्षा के लिए Resource Allocation is Initilization(RAII) नामक एक विशिष्ट मेचांसिम को अनुमति देता है।

Suggestted समाधान:
आप बल्कि स्पष्ट रूप म्युटेक्स अनलॉक से आरए II उपयोग करना चाहिए। आप आरए II को लागू करने के बढ़ावा :: म्युटेक्स :: scoped_lock इस्तेमाल कर सकते हैं:

struct YourStruct 
{ 
    void doSomething() 
    { 
     boost::mutex::scoped_lock l(m_mutex); 
     //do something Interesting 
    } 
    private: 
     boost::mutex m_mutex; 
}; 
+1

मुझे खेद है। कोर से, यह इंगित करता है कि यह म्यूटेक्स के विनाशक में विफल रहता है। और हाँ। यह साबित करने के लिए सिर्फ एक परीक्षण है कि म्यूटेक्स अनलॉक स्थिति में है। # 0x0000003803030265 /lib64/libc.so से raise() में।6 (gdb) जहां # 0 0x0000003803030265 __assert_fail में /lib64/libc.so.6 2 # 0x00000038030296e6 से से /lib64/libc.so.6 # 1 0x0000003803031d10 बीच में बंद करें() में उठाने के() में (से)/lib64/libc.so.6 # 3 0x0000000000416314 बढ़ावा में :: mutex :: ~ mutex()() –

2

POSIX कहा गया है कि एक pthread_mutex_destroy आपरेशन से लौटे केवल त्रुटियों EINVAL हैं म्युटेक्स किसी भी तरह अमान्य है, या EBUSY अगर किसी को उपयोग कर रहा है यह (स्पष्ट रूप से या हालत चर के माध्यम से)।

सबसे अधिक संभावना परिदृश्य दूसरा है।

हालांकि, मुझे आपके किसी भी कोड में m_bLock सदस्य चर में कोई भी परिवर्तन दिखाई नहीं दे रहा है। क्या आप वाकई इस चर को lock और unlock कॉल में बदलना नहीं चाहते हैं?

यदि यह उपयोग में है, तो आपको केवल तब तक इंतजार करना होगा जब तक कि इसका उपयोग करने वाला कोई भी इसे छोड़ने के इच्छुक नहीं है। कोई अन्य विकल्प आपके लिए अच्छा होने की संभावना नहीं है :-)

+0

तो मैं विनाशक में इरनो कैसे प्रिंट करूं? m_bLock के संबंध में, अन्य क्लास लॉक को कॉल करेगी और फ़ंक्शन अनलॉक करेगी ताकि m_bLock बदल दिया जा सके। मैंने यह सुनिश्चित करने के लिए किया है कि म्यूटेक्स अनलॉक स्थिति में है। और विनाशक में, म्यूटेक्स को मेरे परीक्षण के दौरान अनलॉक करने की आवश्यकता नहीं है जिसका अर्थ है कि म्यूटेक्स अनलॉक स्थिति –

+0

@ माइकल में है, यह एक अच्छा मुद्दा है, मुझे अभी एहसास हुआ कि आप लौटने से पहले जोर दे चुके थे ताकि आपको नहीं मिलेगा इरनो प्रिंट करने का मौका (पैक्स उग्र रूप से उसका जवाब संपादित करता है)। आपके दूसरे बिंदु के रूप में, हालांकि कोड _call_ 'लॉक/अनलॉक 'हो सकता है, जो' mbLock' नहीं बदलता है क्योंकि आपके सदस्य फ़ंक्शंस इसे कभी नहीं बदलते हैं। – paxdiablo

3

मुझे एक ही त्रुटि थी (जो मुझे यह प्रश्न मिला)। मैंने प्रासंगिक थ्रेड में join जोड़कर समस्या से हल किया। धागा से पहले मेरी मुख्य प्रक्रिया खत्म हो रही थी और mutex इसे अनलॉक करने से पहले फेंक दिया जा रहा था।

संबंधित मुद्दे