Re: [RFC] locking.9

On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote:
> Julian Elischer wrote:
> 
> >ok so how about I commit this to get us started and the nroff and
> >locking experts can take it from there.
> 
> The first table I think may look like this (from quick reading.. but I may be wrong):
> 
> 
>     The following table shows what you can and can not do if you hold one of
>     the synchronisation primatives discussed here: (someone who knows what
>     they are talking about should write this table)

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].

>     *1 Recursion is defined per lock. lock order is important.

Lock order is always important, not only between the same lock types.
You also can't mix order of acquiring mtx and rw locks, etc.

>     *2 readers can recurse tough writers can not. lock order is important.

I think John or Attilio are working on adding a flag which will allow
for recursion.

>     *3 There are calls atomically release this primative when going to sleep
>     and reacquire it on wakeup (e.g.  mtx_sleep(), rw-sleep() and
>     msleep_spin).()
> 
>     *4 One can also use sx_sleep() which atomically release this primative
>     when going to sleep and reacquire it on wakeup.

What's the difference between 3 and 4? {rw,sx}_sleep(9) fucntions are
quite new and I don't know if you can use then only while
writer/exclusive lock or also while holding reader/shared lock.

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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!