what shall we do when a lock fails

what shall we do when a lock fails

Post by Andy Yan » Mon, 10 Jan 2005 17:36:40


I am pretty new to pthread programming. Currently I am reading David's
Book, Programming with Posix Thread. In Chapter 7, page 261, David gives
out an example on read/write lock. The code is as follows:

int rwl_readlock(rwlock_t *rwl)
if (rwl->w_active){
pthread_cleanup_push(rwl_readcleanup, (void*)rwl);
status = pthread_cond_wait(&rwl->read, &rwl->mutex);
if (status != 0) break;
if (status == 0) rwl->r_active;
return status;

This segment of code return erronous status code back to the user,
in case something goes wrong inside. Here my questions is, in this case,
how shall we deal with the error when we use this read/write lock,
or other similar locks that we build with pthreads routines?

Thanks a lot!


what shall we do when a lock fails

Post by Joseph Sei » Mon, 10 Jan 2005 21:56:14

Abort or throw an exception. The most likely causes are incorrect use
or initialiation of the lock, or something clobbered the lock. There
is no meaningful runtime recovery in either case.

Joe Seigh


what shall we do when a lock fails

Post by David Bute » Fri, 14 Jan 2005 02:22:44


Right. Normal mutex failure returns are serious application programming
errors; not something that MOST code can elegantly handle and continue.
(This is not true for recursive or error-check mutexes.)

There's a tension in designing library code between "ease of
use/simplicity" and "generalization". (And even more tension when the
library code is specifically to illustrate techniques for a book!) The
simplest and easiest-to-use path here would be to simply abort on an
error rather than leave the caller to deal with it. It probably also
makes the most straightforward example, but it also limits the error
handling flexibility of the caller. For example, if the caller aborts it
can report the file and line number of the call site, which might be
relevant in determining what went wrong -- whereas the file and line of
the library routine's call to pthread_mutex_lock() is usually pretty

But you could easily go either way on this decision, because it's
somewhat arbitrary in this sort of context.

Dave Butenhof, XXXX@XXXXX.COM
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062