pthread_mutex_lock prüfen?

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.