Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Frage zu Exception

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
02.05.2005, 22:28 Uhr
AlfameisterT



Hallo,

mal eine allgemeine Verständnissfrage...

Wenn ich in einer Methode selber eine Exception schmeiße, was passiert dann mit dem Object? Die Exception wird außerhalb aufgefangen.
Also die Variablen aus der Methode verlieren ihre denke ich ihre Gültigkeit und werden aufgeräumt. Was passiert mit dem Object?
Die Frage weil mehrere Methoden gelockt sind, wenn das Object nicht gelöscht wird würde es ja nimmer erreichbar sein...



.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
03.05.2005, 13:35 Uhr
RHBaum



Hae ?


Zitat von Verfasser:

Also die Variablen aus der Methode verlieren ihre denke ich ihre Gültigkeit


Ja, wenn du durch die exception die Methode verlaesst ja .... und sie sich selber aufraeumen ...



Zitat von Verfasser:

Was passiert mit dem Object?


Nix weiter du verlaesst die methode so, als haettest du nen return aufgerufen ....
Ausnahme iss glaub ich nur der construktor, wenn da ne exception hasst, wird der "Zurueckgerollt" ...


Zitat von Verfasser:

Die Frage weil mehrere Methoden gelockt sind


Also du rufst in deiner Mothode nen Lock auf ....


C++:
void MeineMethode()
{
    mcs.Lock();
    // was wildes tun
    // hier koennte ne exception geworfen werden
    // weiter im text
   mcs.Unlock();
}


Iss natuerlich nen problem ... weil dein Unlock nich aufgerufen wurde ... besser :


C++:

// irgendwo zugaenglich plazieren ...
template<class LockingClass>
class ObjectLock()
{
public:
    ObjectLock(LockingClass & rxLock):mLock(rxLock)
    {
          mLock.Lock();
    }
    ~ObjectLock()
    {
         mLock.Unlock();
    }
private:
    LockingClass & mLock;
};

// wieder die Methode nun mit LockObject ....
void MeineMethode()
{
    // Beispielseisse wenn CCritical Section als Locker verendest ....
    ObjectLock<CCriticalSection> LockObject(mcs);
    // was wildes tun
    // hier koennte ne exception geworfen werden
    // weiter im text
   // entlocken nich mehr notwendig, sobald die Funktion verlassen wird, wird lock aufgehoben ...
}





Prinzip verstanden ?

Ciao ....

Dieser Post wurde am 03.05.2005 um 13:37 Uhr von RHBaum editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
03.05.2005, 15:22 Uhr
AlfameisterT



Jepp, Prinzip verstanden. Danke für die Antwort

Andere Frage, was wenn ein Lock 2mal aufgerufen wird, z.B. bevor CLock Object zerstört wird eine weitere gelockte Methode aufgerufen wird.
Die beiden CLock Objecte würde vermutlich zerstört werden.
Nur wie ist des beim Mutex. Da wurde ja 2mal Lock aufgerufen, verlangt der auch 2mal unlock? Verwende die PosixThreadsLibrary.

Dieser Post wurde am 03.05.2005 um 15:29 Uhr von AlfameisterT editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
04.05.2005, 15:35 Uhr
RHBaum



Aehm, wenn du 2 mal hintereinander nen Lock auf einen Mutex aufrufst, passiert genau das, was passieren soll ....

der 1. aufruf geht durch,
der 2. aufruf wird am lock blockiert, solange bis:
- a. irgendjemand Unlock auf das object aufruft, vorzugsweisse sollte das der thread sein, der auch das 1. Lock aufgerufen hat ...
- b. dein thread vom BS irgendwie abgeschossen wird ... was bei windows z.B. gar nich so unueblich iss, wenn man den zu lange warten laesst ... Der arbeitet sein "Programm" dann natuerlich nich weiter ab ....

Mutex ist dazu da, um kritische Variablen zu schuetzen ... also zu gewaehrleisten, dass immer nur 1 thread grad gewisse geschuetzte bereiche (variablen) bearbeitet ....

Stell dir nen mutex wie ne ampel vor ... der 1. kommt, ampel is gruen ... der 1. schaltet ampel auf rot und geht weiter ... der 2. kommt, ampel iss rot, und wartet an der ampel....
der 1. kommt irgendwo an wo er nen schlter fuer die ampel hat, und schaltet die ampel auf gruen und geht weiter, der 2. bekommt gruen von der ampel ... er schaltet sie natuerlich sofort auf rot und geht auch weiter, bis er irgendwann die mal wieder auf gruen schaltet ...

Was ist daran unklar ?

Ciao ...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
04.05.2005, 17:08 Uhr
virtual
Sexiest Bit alive
(Operator)


Bei den PThread hängt das Verhalten aber ziemlich extrem von den Flags ab, mit denen man das Mutex erzeugt hat. Dh du kannst es Dir selbst einrichten, wie Du es gerne hättest:
www.mkssoftware.com/docs/man3/pthread_mutexattr_settype.3.asp
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
24.05.2005, 10:13 Uhr
AlfameisterT



Hallo,

war jetzt längere Zeit verhindert.
Danke nochmal für die Antworten.

@RHBaum
Das ganze ist mir, denke ich, schon klar.
Ich hatte die Frage schlecht formuliert.
Gemeint war wenn der selbe Thread 2mal Lock aufruft, z.B. weil synchronisierte Methode A eine Methode B aufruft welche ebenfalls erstmal lockt.
Also mutex.lock() rekursiv vom selben Thread aufgerufen wird.


mfg
Alfa
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
24.05.2005, 19:30 Uhr
Spacelord
Hoffnungsloser Fall


Also ich kenn nur die Windows Mutexe.
Und die halten intern die ID des Threads der momentan der Besitzer vom Mutex ist und nen Rekursionszähler der die Anzahl der erfolgreichen "Locks" des Threads zählt.
Ich denke dass sich das woanders auch nicht anders verhält,sonst wäre es ja ne CriticalSection .
Da unter Windows ein Mutex ein Kernelobjekt ist sollte es keine herrenlosen Mutexe geben.
Stellt dass Betriebssystem fest dass der Thread der das Mutex hält gar nicht mehr existiert und aus irgendwelchen Gründen beendet wurde ohne das Mutex frei gegeben zu haben,setzt Windows die ThreadID und den Rekursionszähler auf 0 und macht das Mutex somit wieder verfügbar.
Also entweder gibst du dein Mutex dann im catch Block frei oder durch ne unbehandelte Ausnahme erledigt sich das Problem von alleine.

MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: