site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com pthread_rwlock_t lock; pthread_rwlock_init(&lock, NULL); pthread_rwlock_rdlock(&lock); pthread_rwlock_rdlock(&lock); // No EDEADLK???? // ignoring the destructor code

From the pthread_rwlock_rdlock(3) manpage: And further: -- 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 (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: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: My understanding of read/write locks is that they are NOT recursive. Am I wrong? Or is this special to Darwin? A thread may hold multiple concurrent read locks. If so, pthread_rwlock_unlock() must be called once for each lock obtained. [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_rw... I see that EDEADLK will only be returned if the lock is held for writing by the current thread. This email sent to site_archiver@lists.apple.com