ich hab ein kleine prograämchen mit 2 threads welceh beide auf den gleichen comport zugreifen können.. eine thread ist ein timer, d.h. er liest zyklisch daten vom comport, und der andere schreib auf knopfdruck daten auf dem comport. Damit nich beide gleichzeit schreiben bzw. lesen können hab ich das mit cirtiacal section syncronisiert.

Ab un zu hängt sich aber das programm auf. Habe rausgefunden, das Thread A in der Critical Section ist, und Thread B auch in die cirtical section will (enterCrictical section). Aber genau bei dieser methode bleibt das progamm hängen. Dürft doch nich passieren?

Er wartet doch bei

EnterCriticalSection (& _critSection)

bis der andere thread

LeaveCriticalSection (& _critSection)

passiert hat oder?

Hab ne dafür ne Mutex klasse geschrieben:

class Mutex{

	CRITICAL_SECTION _critSection;

public:

	//Konstruktor
	Mutex () { InitializeCriticalSection (& _critSection); }
    //Destruktor
	~Mutex () { DeleteCriticalSection (& _critSection); }

	//Lock
	void Acquire (UINT i=0){ TRACE("Before Lock %i\n",i); EnterCriticalSection (& _critSection); TRACE("Lock %i\n",i); }
	//Unlock
    void Release (UINT i=0){ LeaveCriticalSection (& _critSection);TRACE("UnLock %i\n",i);  }

};

EDIT: Wenn er in critical section A geht, sende ich darin noch eine message

::SendMessage(m_hWnd,WM_PR2_DATASTATE,(WPARAM)it->c_str(),NULL);

an
an das fenster in dem ich auch den knopf drücke für datenübertragen..

gibt es probleme mit dem messagehandler?

wenn ich es mit PostMEssage mache schein es zu klappen?

gibt es probleme mit dem messagehandler?

Soll das ein Ratespiel sein? Woher sollen wir wissen, was dein Messagehandler macht.

PS: Schau dir mal RAII an, ist besser für Mutexes (oder wie ist die Mehrzahl).

folgenes gestoßen:

Thread A durchläuft zyklisch folgenden Code und führt eine Message im Fenster X aus:

m_Mutes.Acquire ();
::SendMessage(m_hWnd,WM_PR2_DATASTATE,(WPARAM)it->c_str(),NULL); //Hier hängt er sich auf
m_Mutex.Release();

Zur gleichen Zeit drück ich ein Button im Fenster X, welcher ein
Messageevent OnClick aufruft in dem ich dieses tu:

void CThreadTest::OnBnClickedTransfer()
{
m_Mutes.Acquire ();
...
m_Mutex.Release();

}
d.h. Während er noch die Message der Thread A bearbeitet (welche in Fenster X implementiert ist), drück ich einen Button (welcher in Fenster X sitzt) welcher auch eine Message auslöst.. bumm...

hallo leute, ich hab nochmal bischzen alles durchdebuggt, und bin auf

folgenes gestoßen:

Thread A durchläuft zyklisch folgenden Code und führt eine Message im Fenster X aus:

m_Mutes.Acquire ();
::SendMessage(m_hWnd,WM_PR2_DATASTATE,(WPARAM)it->c_str(),NULL); //Hier hängt er sich auf
m_Mutex.Release();

Zur gleichen Zeit drück ich ein Button im Fenster X, welcher ein
Messageevent OnClick aufruft in dem ich dieses tu:

void CThreadTest::OnBnClickedTransfer()
{
m_Mutes.Acquire ();
...
m_Mutex.Release();

}
d.h. Während er noch die Message der Thread A bearbeitet (welche in Fenster X implementiert ist), drück ich einen Button (welcher in Fenster X sitzt) welcher auch eine Message auslöst.. bumm...

Messages von einem anderen Thread and den UI Thread musst du mit PostMessage verschicken. SendMessage ist blockierend und damit hast du wie "Sehr schön" richtig erkannt hat einen Deadlock.

Edit: Wobei das auch nicht immer hilft. Ich verschiebe den Thread mal nach WinAPI
Edit2: eventuell hilft auch SendMessageAsync ^^
BR
Vinzenz

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

thx jungs

Hab ne dafür ne Mutex klasse geschrieben:

wieso schreibt jemand eine klasse für 3 einfach zu verwendende funktionen?

BorisDieKlinge schrieb:

Hab ne dafür ne Mutex klasse geschrieben:

wieso schreibt jemand eine klasse für 3 einfach zu verwendende funktionen?

weil die leute dank des c++ marketing wahns (und durch die teils diletantischen buchempfehlungen von mitgliedern hiesigen forums) den eindruck gewonnen haben, sie müssten alles, aber auch alles, in klassen stopfen, weil ihr code dann modularer und besser sei, etc. typisch c++'ler halt, machens sich immer komplizierter als nötig :lol:

BorisDieKlinge schrieb:

Hab ne dafür ne Mutex klasse geschrieben:

wieso schreibt jemand eine klasse für 3 einfach zu verwendende funktionen?

weil der destruktor der klasse unheimlich hilfreich ist

weil der destruktor der klasse unheimlich hilfreich ist

aber das critical-section object ist danach auch ungültig, wenn es ein object-member ist. legt man es statisch an, benutzen alle objecte die selbe CS. das bringt auch nix. also besser keine klasse drum herumstricken.

sinnvoller wäre sowas^^

edit: übrigens auch und vor allem wegen Exceptions, die überspringen beim "Wurf" ja einfach das "Release".

Und dein Code funktioniert nicht mal.. Genau deshalb verwendet man Klassen, damit man nicht den Aufruf zu InitializeCriticalSection vergisst.

stimmt. ich blindfisch

Badestrand schrieb:

Abgesehen davon ist es doch auch üblich, eine Mutex- und eine MutexLocker- (o.s.ä.) Klasse zu haben.

nö, mein misslungenes beispiel beweisst doch eindeutig, daß man sowas nicht in klassen packen sollte. wo willst du da das InitializeCriticalSection unterbringen?

edit: übrigens auch und vor allem wegen Exceptions, die überspringen beim "Wurf" ja einfach das "Release".

unter windows hast du dafür '__finally'
übrigens ist SEH weitaus nützlich als C++ exceptions

Badestrand schrieb:

Und dein Code funktioniert nicht mal.. Genau deshalb verwendet man Klassen, damit man nicht den Aufruf zu InitializeCriticalSection vergisst.

stimmt. ich blindfisch

hihi :p

fricky schrieb:

nö, mein misslungenes beispiel beweisst doch eindeutig, daß man sowas nicht in klassen packen sollte. wo willst du da das InitializeCriticalSection unterbringen?

class Mutex{

    CRITICAL_SECTION _critSection;

public:

    Mutex () { InitializeCriticalSection (& _critSection); }
    ~Mutex () { DeleteCriticalSection (& _critSection); }

    void Acquire(){ EnterCriticalSection (& _critSection); }
    void Release(){ LeaveCriticalSection (& _critSection); }
};

class MutexLocker
{
    Mutex& cs;

public:
    MutexLocker( Mutex& m ) : cs(m)
    {
       cs.Acquire();
    }

    ~MutexLocker()
    {
        cs.Release();
    }
};

...
Mutex the_section;
...

void f()
{
   MutexLocker m (the_section);
   // Locked
   ...
} // Unlocked

Meinetwegen auch mit "friend", damit man auf Aquire und Release keinen Zugriff mehr hat

class Lock {

private:

    Mutex & _mutex;

public:
    // Acquire the state of the semaphore
    Lock (Mutex &mutex): _mutex(mutex){
        _mutex.Acquire();
    }

	// Release the state of the semaphore
    ~Lock (){ _mutex.Release();	}

};

sowas hab ich auch noch^^ immer cool bleiben

Gut, man kann ja nie wissen

fricky schrieb:

Badestrand schrieb:

edit: übrigens auch und vor allem wegen Exceptions, die überspringen beim "Wurf" ja einfach das "Release".

unter windows hast du dafür '__finally'

Joar, aber dann musst du ja schon wieder an was denken, ich mag's automatisch (beim Programmieren)

fricky schrieb:

übrigens ist SEH weitaus nützlich als C++ exceptions

Das verstehe ich nicht, sind die C++-Exceptions nicht genau "Structured Exception Handling"?

Ich frage mich wieso es überhaupt eine Dead-lock gibt?????

Wenn ich mit SendMessage eine Msg an das Fenster schicke, ich dann glichzeitig ein button im fenst drücke, können doch keine messages parallel barbeitet wrden oder? d.h. solange die message queue die click message des button bearbeiten, kann der thread doch keine message schicken??? zudem wir in der Klick message aufruffe des Mutex gsperrt, der thread kann schon mal gar keine message schicken? bin verwirrt.

manfng ds

*very*

BorisDieKlinge schrieb:

Ich frage mich wieso es überhaupt eine Dead-lock gibt?????

Ist doch logisch, die Funktion "SendMessage" ruft die WndProc auf, die wiederum den Mutex haben will, der aber von der aufrufenden Funktion belegt ist.

m_Mutes.Acquire (); // Locked

//::SendMessage(m_hWnd,WM_PR2_DATASTATE,(WPARAM)it->c_str(),NULL); //Hier hängt er sich auf
// Führt onBnClickedTransfer hier aus:
    m_Mutes.Acquire (); // Ist schon gelockt, DeadLock
    ...
    m_Mutex.Release(); 

m_Mutex.Release();

Also einfach PostMessage nehmen, da wird die Nachricht in die Message-Queue gedrückt und die Funktion kommt sofort zurück. Danach kann auch das Aquire aus onBnClickedTransfer greifen

wenn ich m_Mutes.Acquire (); mache, und schon gelockt ist, müsste er doch da warten bis der Mutex wieder freigegeben ist...

wenn ich m_Mutes.Acquire (); mache, und schon gelockt ist, müsste er doch da warten bis der Mutex wieder freigegeben ist...

Ja klar, aber wie soll er bei diesem linearen Programmstückchen wieder freigegeben werden?:

Mutex m;
m.Aquire();
m.Aquire();
m.Release();
m.Release();

Und genau so läuft das bei deinem Programm momentan ja ab

Falls das noch nicht so ganz klar geworden ist: Bei SendMessage springt dein Thread (der SendMessage ausführt) in deine WndProc und läuft dort ja direkt in's nächste Aquire. Erst wenn die Abarbeitung der WndProc fertig ist, ist die SendMessage-Funktion "fertig" und das Release nach dem SendMessage wird ausgeführt.