Date: Mon, 5 Jan 2004 19:28:48 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Earl Chew <earl_chew@agilent.com> Cc: freebsd-threads@freebsd.org Subject: Re: misc/24641: pthread_rwlock_rdlock can deadlock Message-ID: <Pine.GSO.4.10.10401051903260.17382-100000@pcnet5.pcnet.com> In-Reply-To: <200401052230.i05MUEov039020@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@agilent.com> > To: aspiesrule@mcleodusa.net > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: misc/24641: pthread_rwlock_rdlock can deadlock > Date: Mon, 05 Jan 2004 14:21:00 -0800 > > aspiesrule@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10401051903260.17382-100000>