Hallo, mal so, prüft ihr den Rückgabewert von pthread_mutex_lock, oder ist da sowieso schon das Kind in den Brunnen gefallen wenn der Aufruf fehlschlägt? Und: Wie viele Threads dürfen maximal gleichzeitig auf einen Mutex warten? Werner
Werner schrieb: > prüft ihr den Rückgabewert von pthread_mutex_lock Ja. > oder ist da > sowieso schon das Kind in den Brunnen gefallen wenn der Aufruf > fehlschlägt? Wenn der Aufruf fehlschlägt, dann läuft etwas anders, als du es erwartet hast. Die man-Page listet mögliche Gründe für ein Fehlschlagen auf. Kannst du vorab sämtliche Fehlerszenarien ausschließen? Vermutlich nicht. Also prüfen. > Wie viele Threads dürfen maximal gleichzeitig auf einen Mutex > warten? Soviele, wie deine Thread-Implementierung bzw. dein Rechner zulassen, nehme ich an. Für pthread_mutex_lock() ist zumindest kein Limit angegeben.
Werner schrieb: > mal so, prüft ihr den Rückgabewert von pthread_mutex_lock, oder ist da > sowieso schon das Kind in den Brunnen gefallen wenn der Aufruf > fehlschlägt? Je nachdem, welcher Fehler auftritt, mag es zwar in den Brunnen gefallen sein, aber willst du dann in deinem Programm einfach so weitermachen, als hätte alles funktioniert und deinen Zugriff auf was auch immer du synchronisierst dann stillschweigend ohne Mutex-Lock machen?
Rolf M. schrieb: > Je nachdem, welcher Fehler auftritt, mag es zwar in den Brunnen gefallen > sein, aber willst du dann in deinem Programm einfach so weitermachen, > als hätte alles funktioniert Natürlich nicht. Alle dokumentierten Fehler sind letzendlich Programmierfehler. Also sollte man dafür sorgen, dass sie behoben werden:
1 | err = pthread_mutex_lock(...); |
2 | if (err != 0) { |
3 | log("Timmy ist in den Brunnen gefallen", err); |
4 | abort(); // oder was auch immer |
5 | }
|
In einem Embedded-Programm, das nicht einfach abbrechen darf, ist die korrekte Fehlerbehandling nicht so einfach ...
Nun ja, alle und immer sind meistens pauschal falsch. Ob z.B. der Fall, daß ein Thread ein lock anfordert, obwohl er es schon hat, ein Programmierfehler ist, oder nicht, darüber lässt sich streiten. Solange das Programm darauf passend reagiert, ist alles in Ordnung. Oliver
Oliver S. schrieb: > Ob z.B. der Fall, daß ein Thread ein lock anfordert, obwohl er es schon > hat, ein Programmierfehler ist, oder nicht, darüber lässt sich streiten. Wenn es kein Fehler sein soll, muss man PTHREAD_MUTEX_RECURSIVE verwenden.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.