Date: Mon, 24 Jan 2011 17:18:39 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: threads@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: Try upgrades and downgrades for POSIX rwlocks Message-ID: <20110125011839.GK21872@elvis.mu.org> In-Reply-To: <201101241604.21451.jhb@freebsd.org> References: <201101241604.21451.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@freebsd.org> [110124 13:05] wrote: > Does anyone know if there is a de facto or proposed standard for supporting > upgrades and downgrades in POSIX rwlocks? IBM seems to support something > rather gross where a wrlock() will succeed if the only shared lock is held by > the current thread. But then the thread holds both a read and write lock, and > it has to call unlock twice, the first to drop the write lock, the second to > drop the read lock. If we were to add support for upgrades and downgrades I > would prefer something more along the lines of our in-kernel APIs where there > are try_upgrade() and downgrade() operations that convert a given lock between > states. There may a be a tricky problem here. In order to avoid writer starvation (in the kernel) we give writers preference over readers so that many concurrent readers can't keep the lock in a shared-only state forever. (Or at least that's how I left it when I touched it last. :D ) There is a problem here. To conserve that behavior we need to look at the situation of an upgrade: 1) we have to put the upgrader to the front of the writer queue, this can starve other threads looking for only a writer lock by giving an unfair advantage to those that take a share lock first. 2) we don't even look at this issue and we wind up with some deadlock. At a glance, I think we have to have some kind of "try_upgrade" that doesn't give preference to the thread already holding the lock. We should probably strongly encourage try_upgrades to have some sort of fault injection so that a potentially infrequently "missed upgrade" path can be exercised easily. Perhaps with a kernel config option or that fault injection stuff? just some ideas. Maybe there's someone that can explain how IBM does the rwlocks. Why do we want to have our own method. And if our methods are different, does it break the semantics that may become standard across the board? Does it help us to diverge? What about OS X and Solaris? -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110125011839.GK21872>