misc/24641: pthread_rwlock_rdlock can deadlock
davidxu at freebsd.org
Mon Jan 5 22:53:55 PST 2004
Daniel Eischen wrote:
>It shouldn't fail; it should deadlock.
>>>It may seem trivial to implement this, but when you consider
>>>that there may be a lot of readers then it is not so trivial.
>>>In order to implement it, you need to know whether a thread
>>>owns the rdlock and have a recurse count for it.
>>Hmm... doesn't P2 already require you to support recursion?
>The implementation just keeps one count of total readers (i.e.,
>recursion by a group of readers); this is stored in the rwlock.
>Recursive rdlocks by the same thread count as multiple readers.
>There is no per-thread counter. For recursive _mutexes_ this
>is simple because there can be only one owner so the one recurse
>count stored in the mutex is sufficient. But for rwlocks there
>can be lots of readers, and each reader may hold multiple rwlocks.
>You either need a queue to hold the rwlock status (pointer to
>rwlock and recurse count) for each owned rwlock in each thread,
>or you need a queue of thread status (pointer to thread and
>recurse count) for each owning thread in each rwlock. And
>regardless of where you store the queue, you need to seach it
>to see if the thread already owns the rdlock (and then again
>on the rdunlock).
>Think about it. What if you have 100 threads rdlock recursing
>on 1 rwlock? How do you tell if threads already own a rwlock?
>And how many times have they recursed on the rwlock? And what
>if threads want to own multiple rwlocks?
>Our current implementation is rather simple, but it does
>avoid us from having to build in limits as to how many
>rwlocks can be owned by a thread or how many threads can
>own a rwlock. I'll add this to my TODO list for libkse
>but it will come at a bit of a performance & storage
>cost and there will have to be some built-in limits.
These information should be written into manual, so nobody will repeatly
ask this question. :-)
More information about the freebsd-threads