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: Gwynne Raskind <email@hidden>
- Date: Wed, 27 May 2009 13:57:50 -0400
On May 27, 2009, at 1:43 PM, Karan, Cem (Civ, ARL/CISD) wrote:
I've been busy writing unit tests for an Objective-C wrapper of mine
that wraps pthread read/write locks. One of my unit tests should
fail with EDEADLK, but I never have that happen. My test code
essentially boils down to the following, all of which is run from
one thread only:
pthread_rwlock_t lock;
pthread_rwlock_init(&lock, NULL);
pthread_rwlock_rdlock(&lock);
pthread_rwlock_rdlock(&lock); // No EDEADLK????
// ignoring the destructor code
My understanding of read/write locks is that they are NOT
recursive. Am I wrong? Or is this special to Darwin?
From the pthread_rwlock_rdlock(3) manpage:
A thread may hold multiple concurrent read locks. If so,
pthread_rwlock_unlock() must be called once for each lock obtained.
And further:
[EDEADLK] The current thread already owns rwlock for
writing.
My interpretation of this is that you can hold as many read locks as
you like, recursively, and that EDEADLK will only show up when you try
to take a write lock when you already have a read lock.
The manpage names itself as being BSD, not Darwin, so I would imagine
(but not know!) that this is a characteristic of at least one of the
flavors of BSD that Darwin derives from.
Finally, having a look at the source code for pthread_rwlock_rdlock()
at:
http://www.opensource.apple.com/source/Libc/Libc-498.1.7/pthreads/pthread_rwlock.c
I see that EDEADLK will only be returned if the lock is held for
writing by the current thread.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
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