[RFC] locking.9
Robert Watson
rwatson at FreeBSD.org
Wed Mar 14 09:17:04 UTC 2007
On Wed, 14 Mar 2007, Pawel Jakub Dawidek wrote:
> I think it should be:
>
>> You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep
>> SPIN mutex ok no no no no-3
>> Sleep mutex ok ok-1 no ok no-3
>> sx_lock ok no ?? no ok-4
> sx_lock ok ok ok-2 ok ok
>> rw_lock ok no no ok-2 no-3
> rw_lock ok ok no ok-2 no
>
> And I'd sort the table a bit differently: spin, mtx, rw, sx[, sleep].
Hmm. I was thinking more along the lines of a table that compared properties
and locks. I.e., horizontally feature, vertically lock type. Features would
be things like "safe in interrupt handlers", "can perform unbounded sleep
while holding", "supports multiple readers, not just exclusion", "priority
propagation", etc.
> BTW. I just wake up with a feeling that I did something wrong in my code. I
> thought about it for a moment and it seems I'm right. When one always use
> rw/sx locks this way:
>
> sx_xlock();
> /* do work */
> sx_downgrade();
> /* do work */
> sx_sunlock();
>
> (the same for rw(9)) the lock will _never_ be shared, because one still
> always acquire exclusive lock first, which serialize synchronization. Is my
> thinking correct? If so, I think it's not very obvious, so we may want to
> add a comment about such use to the manual page as well.
FYI, one of the problems with "downgrade" as a primitive is that if you always
acquire exclusively and then downgrade, you never get multiple shared readers,
as all shared readers must first go through an exclusive stage. It only helps
if you have threads entering as shared from inception. This is one reason why
naively moving to reader/writer locks doesn't solve concurrency limits in the
TCP input path.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list