Threads, CSemaphor, CSinglelock und Assertion in mtex.cpp



  • Hallo zusammen,
    ich habe ein ärgerliches Problem. Jedes mal, wenn ich mein Programm ausführe erhalte ich einen Assertion Alert in mtex.cpp in Zeile 106:

    BOOL CSingleLock::Lock(DWORD dwTimeOut /* = INFINITE */)
    {
    	ASSERT(m_pObject != NULL || m_hObject != NULL);
    	ASSERT(!m_bAcquired); //<<<<< Zeile 106
    
    	m_bAcquired = m_pObject->Lock(dwTimeOut);
    	return m_bAcquired;
    }
    

    Hier mein Weg um die Threads zu erzeugen:

    CSemaphore *mySemaphore;
    mySemaphore = new CSemaphore(nThreads,nThreads);
    CSingleLock mySingleLock(mySemaphore, true);
    
    mySingleLock.Lock(); //<<<< Hier tritt der Fehler auf
    AfxBeginThread(MyControllingFunction, threadHQ[threadCount]);
    

    Wenn ich oft genug auf ignorieren oder wiederholen klicke, wird die Aufgabe im Thread jedoch meistens erfüllt, auch wenn das Programm letztendlich abstürzt.

    Ich hoffe jetzt eigentlich nur, dass jemandem hier dieser Fehler eventuell bekannt vorkommt da ich nicht sehr viel weiteren Code posten kann. Im Thread greife ich Inhalte von Websites ab, aber ich denke nicht, dass es damit etwas zutun hat. Irgendwas im CSingeleLock ist kaputt.

    Kennt also evtl jemand von euch diesen Fehler oder kann mich ein wenig auf den richtigen Weg schubsen? Welche einfache Alternative gäbs noch zu CSingleLock ?

    Vielen Dank im Vorraus



  • CSemaphore *mySemaphore;
    mySemaphore = new CSemaphore(nThreads,nThreads);
    CSingleLock mySingleLock(mySemaphore, true);
    
    mySingleLock.Lock();
    mySingleLock.Lock(); //<<<< Hier tritt der Fehler auf
    

    Ich habe zu wenig Infos geliefert und konnte den Fehler jetzt etwas eingrenzen.
    Das Problem tritt bei mir immer dann auf, wen ich mySingleLock.Lock(); ein zweites mal ausführe, wie im obigen Beispiel gezeigt.



  • So jetzt konnte ich den Fehler beheben und kann damit das Selbstgespräch beenden 😉

    Ich möchte noch eben die Lösung anbieten, falls sonst noch jemand auf dieses Problem stöst. Der Fehler war, das ich die implementation von Semaphoren bzw. threadsicheren Klassen noch nicht richtig verstanden hatte.

    Die beiden genannten Beispiele habe ich in einer einfachen Methode ausgeführt.

    Ich dachte mir "Resource sperren und dann Thread starten". So funktioniert dass aber nicht. In der MyControllingFunction greife ich auf eine Klasse zurück. Die ganzen CSemaphor Sachen gehören in diese Klasse auf die ich aus dem Thread heraus zugreife.

    Ich habe den Semaphor und den SingleLock also in diese Klasse eingebunden und nun gilt sie als threadsicher und es funktioniert alles ganz Klasse.


Anmelden zum Antworten