site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com http://www.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdloc... -- Greg Parker gparker@apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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)." 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.) This email sent to site_archiver@lists.apple.com