On Sun, Aug 31, 2014 at 6:23 PM, Ryota Ozaki <[email protected]> wrote: > Hi darrenr and rmind, > > Thank you for your replying, and I'm sorry for not replying yet. > I'm now in a busy period for several weeks. I'll be back at the > next weekend.
I'm back finally. I needed one more month than I expected... Anyway I'm replying pending mails. Thanks, ozaki-r > > ozaki-r > > On Tue, Aug 26, 2014 at 4:49 AM, Mindaugas Rasiukevicius > <[email protected]> wrote: >> Ryota Ozaki <[email protected]> wrote: >>> Hi, >>> >>> I thought I need more experience of pserialize >>> (and lock primitives) to tackle ifnet work. >>> So I suspended the work and now I am trying >>> another easier task, bpf. >>> >>> http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff >>> >> >> As Darren mentioned - there are various bugs in the code (also, malloc >> change to M_NOWAIT is unhandled). You cannot drop the lock on the floor >> and expect the state to stay consistent. Something has to preserve it. >> >> The following pattern applies both to the locks and pserialize(9): >> >> pserialize_read_enter(); >> obj = lookup(); >> pserialize_read_exit(); >> // the object is volatile here, it might be already destroyed >> >> Nothing prevents obj from being destroyed after the critical path unless >> you acquire some form of a reference during the lookup. >> >>> BTW, I worry about there is no easy way to >>> know if a function in a critical section >>> blocks/sleeps or not. So I wrote a patch to >>> detect that: http://www.netbsd.org/~ozaki-r/debug-pserialize.diff >>> Is it meaningful? >> >> Why per-LWP rather than per-CPU diagnostic counter? On the other hand, if >> we start adding per-CPU counters, then we might as well start implementing >> RCU. :) >> >> -- >> Mindaugas
