Fehlerbehandlung
Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
SP-Klausur: Jbuffer/Semaphore Fehlerbehandlung
Guten Abend,
Ich habe mir gerade noch einmal meine Implementierung der Semaphor angesehen, und möchte - in Anbetracht, dass in Klausuren gerne “die()” genutzt wird - gerne wissen, wie man bei einem Fehler einer beliebigen pthread-Funktion bei einer Fehlerbehandlung vorgeht.
Grundsätzlich gibt es zwei Möglichkeiten:
- Stirb Prozess, Stirb!, was ich etwas drastisch finde, aber der Prozess ja nicht mehr ordnungsgemäß weitergeführt werden kann:
if(pthread_mutex_lock(&c->mutex)) die("lock"); - errno setzen, returnen, und dann im Hauptprogramm reagieren (und ggf. da sterben ;)):
if((errno = pthread_mutex_lock(&c->mutex)) != 0) return; Denk’ dran, dass die errno threadlokal ist.
Wenn du das also aus einem beliebigen (Nicht-Haupt-) Thread heraus machst, solltest du es irgendwie in den Rückgabewert packen und dann im Hauptthread weiterschauen.
Für dein konkretes Beispiel hab ich mal in die man page geschaut. Die Vielfältigkeit der Fehlerzustände geht glaube ich (hoffe ich) ein wenig über SP hinaus. 
Wie man das außerhalb von SP angeht wäre trotzdem recht interessant. Es gab da ja auch diese diversen Konfigurationsmöglichkeiten mit pthread_attr_t *attr…
Wann kann pthread_mutex_lock() denn fehlschlagen?
Das kommt wohl darauf an, was für ein mutex es ist.
pthread_mutex_lock(3P) verwendet ein paar Zeilen darauf, das für den jeweiligen Typ zu beschreiben, wir haben aber nur die default settings verwendet:
pthread_mutex_init(&mutex, NULL)Wenn ich den 1. Satz richtig verstehe:
The mutex object referenced by mutex shall be locked by a call to pthread_mutex_lock() that returns zero or [EOWNERDEAD]., dann kann allgemein dieser Fehlerwert zurückgegeben werden, der mutex ist dann aber trotzdem gelockt und der Thread, der den Aufruf gemacht hat, besitzt jetzt diesen Mutex. Der Fehler kann dann also getrost ignoriert werden, sofern man sich nicht für das Ableben des anderen Threads interessiert.
EDIT: Der Teil mit dem Besitzwechsel bezieht sich wohl nur auf “robust mutexes”. Ich fühle mich von der manpage im Stich gelassen…
Wann kann das auftreten?
ENOTRECOVERABLE
The state protected by the mutex is not recoverable.Ja, das ist ne hübsche Idee, nur leider geht das bei void so schlecht 
Das mit errno zu lösen wäre natürlich hübsch - wenn auch nervig, wenn man das dann in seinem Programmierteil permanent machen muss …
Hab ich dich hier missverstanden?
denn: void* != void
und auf die errno kannst du nach dem return nicht mehr zugreifen.
EDIT: Ah, returnen möchtest du von irgendeiner Funktion, mit Hauptprogramm meinst du deinen aktuellen Thread. Sorry, es ist schon spät.
Jop, genau so. Hab eine Funktion, die void zurückgibt, und die wird von einem Thread aufgerufen. in der Funktion selbst wird der mutex gelockt, und jetzt interessiert mich, wie man das am schönsten behandelt. Beziehungsweise, ob ein die(„lock“) gerechtfertigt ist 
Schau dir doch mal die Manpage dazu genauer an. In der Regel musst du für pthread_mutex_lock überhaupt keine Fehler abfangen. (Was soll beim lock denn schiefgehen?)
[m]pthread_mutex_{lock,unlock}()[/m] kann nur schiefgehen, wenn ihr die Operation im Code falsch benutzt. Das ist folglich ein statischer Programmierfehler, den man nicht abfangen muss. Das ist ähnlich wie bei [m]sigaction()[/m] - das kann auch nur fehlschlagen, wenn man ihm eine ungültige Signalnummer oder einen ungültigen Zeiger übergibt.
Fehlerabfragen sind essenziell bei dynamisch auftretenden Fehlern - Fehlern, über die man nicht vorab sagen kann, ob sie zur Laufzeit auftreten werden oder nicht (reicht der Speicher? existiert die Datei wirklich? hat der Aufrufer die richtige Anzahl Argumente übergeben?).
1 Like