Re: [RFC] locking.9

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.

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [RFC] locking.9
    ... Lock order is always important, not only between the same lock types. ... when going to sleep and reacquire it on wakeup. ...
    (freebsd-current)
  • Re: [RFC] locking.9
    ... the synchronisation primatives discussed here: ... *1 Recursion is defined per lock. ... lock order is important. ... mutexes case) and that very soon all the primitives will allow ...
    (freebsd-current)