Date: Tue, 25 Jan 2011 08:17:11 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: threads@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: Try upgrades and downgrades for POSIX rwlocks Message-ID: <20110125161711.GT21872@elvis.mu.org> In-Reply-To: <AANLkTindC3a4iaHx=ioGvwD1KxmNpBTRxVHLvsWNRWNe@mail.gmail.com> References: <201101241604.21451.jhb@freebsd.org> <AANLkTindC3a4iaHx=ioGvwD1KxmNpBTRxVHLvsWNRWNe@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Attilio Rao <attilio@freebsd.org> [110125 08:09] wrote: > 2011/1/24 John Baldwin <jhb@freebsd.org>: > > 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. > > I'd support us adopting the same semantic rwlock in kernel space have. > An alternative semantic would be what lockmgrs do: > - try to upgrade > - if failed (more than one shared owner then): > * drop our shared lock > * try a normal exclusive acquisition > > That seems like more linear, even if I'm very much more in favor of > not having something like that (infact, removing LK_UPGRADE is one of > my personal target, as such operation can be implemented in consumers > themselves as well, if they want). In my opinion the implicit drop semantic is really an error prone API and makes the code hard to read. I agree the LK_UPGRADE stuff is scary. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110125161711.GT21872>