Date: Tue, 25 Jan 2011 16:40:07 +0100 From: Attilio Rao <attilio@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: <AANLkTindC3a4iaHx=ioGvwD1KxmNpBTRxVHLvsWNRWNe@mail.gmail.com> In-Reply-To: <201101241604.21451.jhb@freebsd.org> References: <201101241604.21451.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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). Attilio -- Peace can only be achieved by understanding - A. Einsteinhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTindC3a4iaHx=ioGvwD1KxmNpBTRxVHLvsWNRWNe>