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: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Thu, 28 May 2009 07:08:13 -0400
- Thread-topic: Why isn't pthread_rwlock_rdlock() deadlocking???
First off, I apologize for messing up the subject line in my last post;
I hit the send button a little too quickly.
Greg Parker wrote on Wednesday, May 27, 2009 4:40 PM
> 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/pthrea
> d_rwlock_rdlock.html
That is MUCH clearer! Unless someone has already modified the man
pages, I'll file a bug report requesting that they change the page to
match the above.
>
> > 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.)
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.
Thanks,
Cem Karan
_______________________________________________
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