misc/24641: pthread_rwlock_rdlock can deadlock

Daniel Eischen eischen at vigrid.com
Mon Jan 5 16:28:52 PST 2004

On Mon, 5 Jan 2004, Earl Chew wrote:

> The following reply was made to PR misc/24641; it has been noted by GNATS.
> From: Earl Chew <earl_chew at agilent.com>
> To: aspiesrule at mcleodusa.net
> Cc: freebsd-gnats-submit at freebsd.org
> Subject: Re: misc/24641: pthread_rwlock_rdlock can deadlock
> Date: Mon, 05 Jan 2004 14:21:00 -0800
>  aspiesrule at mcleodusa.net wrote:
>  > Same results, except for the fact that stepping thru your code in GDB yields 
>  > a segfault in KERNEL32!IsBadWritePtr.
>  It must be the holidays! Ok, I've added the missing line at the
>  beginning of wrfunc().

POSIX says that:

  If the Thread Execution Scheduling option is supported, and
  the threads involved in the lock are executing with the scheduling
  policies SCHED_FIFO or SCHED_RR, the calling thread shall not
  acquire the lock if a writer holds the lock or if writers of
  higher or equal priority are blocked on the lock; otherwise,
  the calling thread shall acquire the lock.

Forget about the writer's priority for a moment; we don't
currently honor that.  And FYI, SCHED_OTHER in FreeBSD is

POSIX also says that:

  A thread may hold multiple concurrent read locks on rwlock (that
  is, successfully call the pthread_rwlock_rdlock() function n
  times). If so, the application shall ensure that the thread
  performs matching unlocks (that is, it calls the
  pthread_rwlock_unlock() function n times).

It isn't clear to me that this means that a subsequent rdlock
request while there are writers blocked on the lock succeeds.

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.  And threads
may own multiple read locks.  You would have to track all
of them and it would add a bit of overhead having to search
the owned read locks (and they don't have to be taken and
released in order so you'd have to search the entire queue).

More information about the freebsd-threads mailing list