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>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/1/24 John Baldwin <jhb@freebsd.org>: > Does anyone know if there is a de facto or proposed standard for supporti= ng > upgrades and downgrades in POSIX rwlocks? =C2=A0IBM seems to support some= thing > rather gross where a wrlock() will succeed if the only shared lock is hel= d by > the current thread. =C2=A0But 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. =C2=A0If we were to add support for upgrades and down= grades I > would prefer something more along the lines of our in-kernel APIs where t= here > are try_upgrade() and downgrade() operations that convert a given lock be= tween > 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 --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTindC3a4iaHx=ioGvwD1KxmNpBTRxVHLvsWNRWNe>