Re: [RFC] locking.9

2007/3/14, Julian Elischer <julian_at_elischer.org>:
> 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)
>
>           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
>           rw_lock              ok        no      no      ok-2    no-3
>
>     *1 Recursion is defined per lock. lock order is important.
>
>     *2 readers can recurse tough writers can not. lock order is important.
>
>     *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.

I think that we can do a better job describing the three main events
(spinning, blocking, sleeping) the correspondence with every primitive
and what is allowed to do (we can add an addictional paragraph about
preemption and its nits, sched_bind, sched_pin, critical sections,
etc.).

Assuming that lock ordering is always important (not only in the
mutexes case) and that very soon all the primitives will allow
recursion (check for //depot/user/attilio/attilio_smpng/... for an
example fo recursive sx), it is not really important to deal with
these details.
I think would help having a section per-primitive describing the
better cases of usage for every primitive, i.e.:

Spin Mutexes
- To be used only in interrupt context or for path really short, as
single assignment etc (even if in that case probabilly they can be
replaced by something more appropriate.

This informations should be just integrative with the table you
previously mentioned and should not overlap.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein