[RFC] locking.9
Julian Elischer
julian at elischer.org
Wed Mar 14 17:22:06 UTC 2007
Attilio Rao wrote:
> 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.
when you get a few moments, check it out and add these features :-)
That's why I committed it.. to give people something to start with
so that they can add to it if they have just a few minutes free.
>
> This informations should be just integrative with the table you
> previously mentioned and should not overlap.
>
> Attilio
>
>
More information about the freebsd-current
mailing list