Re: Why isn't pthread_rwlock_rdlock() deadlocking???
Re: Why isn't pthread_rwlock_rdlock() deadlocking???
- Subject: Re: Why isn't pthread_rwlock_rdlock() deadlocking???
- From: Wade Tregaskis <email@hidden>
- Date: Thu, 28 May 2009 12:16:28 -0700
pthread deadlock detection is optional in the standard. Even
something as simple as two consecutive pthread_mutex_lock()
calls will hang instead of returning EDEADLK. (And given the
amount of code in the world that fails to check the return
value, that's probably a good thing.)
Unfortunate but true! Are there any options that can be turned on to
enable all the optional debug parts? I'm thinking something like the
malloc environment variables, like MallocScribble. Otherwise, I'm
going
to have to roll my own test code into the wrapper that I'm writing,
but
that will be significantly less efficient than using a prebuilt debug
library.
Not that I'm aware. For mutexes you can specify an explicit attribute
at initialisation time, with the type set to PTHREAD_MUTEX_ERRORCHECK
(see man pthread_mutexattr_settype), which should enable deadlock
detection. Alas, rwlocks don't have an equivalent attribute setting.
Looking at the Darwin source, iff pthreads is compiled with
__DARWIN_UNIX03 defined, then some deadlock detection is enabled -
such as when trying to take a read or write on the lock if you already
hold it for writing - but I don't know if it's compiled that way on
Mac OS X.
Wade
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden