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>
index | next in thread | previous in thread | raw e-mail
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).home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10401051903260.17382-100000>