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: Terry Lambert <email@hidden>
- Date: Thu, 28 May 2009 16:06:13 -0700
On May 28, 2009, at 12:16 PM, Wade Tregaskis wrote:
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.
There are multiple compilation environments available; see the
comments in <sys/cdefs.h> for details. The internal tag that you're
looking at (__DARWIN_UNIX03 ) is a derived tag and should not be used
directly; internally, it just means "UNIX 2003 conformat APIs plus
Apple APIs not covered by the UNIX standard".
The answer is that if you are targeting Leopard or later using
supported development environments for Leopard or later, you're going
to get the UNIX conformant behaviour by default, which will get you
the checks you're wanting to get, and get you the error return.
For any UNIX conformant system where the behaviour is "implementation
defined", you should probably avoid using the interface the way you're
trying to use it, since it's going to render your code non-portable to
any implementation that defines the behaviour differently. However,
for any UNIX implementation which has passed certification (like Mac
OS X Leopard), you can find out what the implementation does with the
implementation questionnaire responses, which is on file with The
OpenGroup, <http://www.opengroup.org>.
The lack of checking is required for binary backward compatibility, to
not change the behaviour of programs which have, for reasons of their
own, written code which deadlocks, and, rather than eliminating the
deadlocks, they've come up with some mechanism of their own for
dealing with them (like alarm()'ing out of the blocking call), and
effectively now depend on the deadlock behaviour.
Given that you are using POSIX interfaces, you should probably be
using that compilation environment, but I can't tell you to target
only Leopard or later with your code, that'd have to be your
decision. If you don't, however, you'll either have to avoid causing
deadlocks by writing standards compliant code, or you'll have to come
up with your own coping mechanism for dealing with them, like other
have with their pre-Leopard code.
When we did the standards conformance effort, there were a lot of
places where we had to maintain the old behaviour for binary backward
compatibility, and provide the new behaviour in a different
compilation environment, to avoid introducing binary compatibility
issues. In LibSystem alone, there are 174 cases of this:
% nm /usr/lib/libSystem.B.dylib | grep UNIX2003 | wc -l
174
Obviously, there are also cases where frameworks reflect untranslated
(raw UNIX) types or values through their own APIs, and those also have
similar issues that had to be addressed by their maintainers.
Yeah, it's kind of annoying, if you are only coming to the UNIX table
now, instead of years ago when the changes first went in, and are
wanting to support OS releases from years ago without multiple
binaries, but if you don't take the standards-compliant compilation
environment, you don't get the protections and behavioural guarantees
the environment offers you.
I like to think of it as additional incentives for making the switch
to standards compliant code.
-- Terry
_______________________________________________
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