misc/24641: pthread_rwlock_rdlock can deadlock

[Daniel Eischen]

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
SCHED_RR.

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).