Re: [RFC] locking.9

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