Try upgrades and downgrades for POSIX rwlocks

Alfred Perlstein alfred at
Tue Jan 25 16:17:13 UTC 2011

* Attilio Rao <attilio at> [110125 08:09] wrote:
> 2011/1/24 John Baldwin <jhb at>:
> > 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 

- Alfred Perlstein
.- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10
.- FreeBSD committer

More information about the freebsd-threads mailing list