Re: Darwin-dev Digest, Vol 6, Issue 119
Re: Darwin-dev Digest, Vol 6, Issue 119
- Subject: Re: Darwin-dev Digest, Vol 6, Issue 119
- From: Greg Parker <email@hidden>
- Date: Wed, 27 May 2009 13:40:26 -0700
On May 27, 2009, at 1:19 PM, Karan, Cem (Civ, ARL/CISD) wrote:
Interesting. My interpretation was that one thread could hold as many
DIFFERENT r/w locks at one time as it wanted (which really confused
me,
locks would be quite useless if you COULDN'T do so, but that is what I
got out of "...for each lock obtained")
"For each lock obtained" is supposed to mean "for each successful
rdlock call". The POSIX description is more explicit:
"A thread may hold multiple concurrent read locks on rwlock (that is,
successfully call the pthread_rwlock_rdlock() function n times). If
so, the thread must perform matching unlocks (that is, it must call
the pthread_rwlock_unlock() function n times)."
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdlock.html
Reading the code makes it much clearer though; thank you! I did one
other stupid test; I locked for reading and then tried to lock for
writing. I seem to have deadlocked without an error on that one.
Unless that is considered normal behavior, once I confirm that it
isn't
a problem with my test code, I'll file a bug about it.
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.)
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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