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 > >Received on Wed Mar 14 2007 - 16:22:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:06 UTC