Date: Tue, 26 May 2009 14:49:51 -0400 From: John Baldwin <jhb@freebsd.org> To: Kip Macy <kmacy@freebsd.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r192604 - in user/kmacy/releng_7_2_fcs/sys: dev/hwpmc sys Message-ID: <200905261449.52153.jhb@freebsd.org> In-Reply-To: <3c1674c90905261141n44bc7c24h5b82a2e25b84f1eb@mail.gmail.com> References: <200905222145.n4MLjhm3019802@svn.freebsd.org> <200905261437.49148.jhb@freebsd.org> <3c1674c90905261141n44bc7c24h5b82a2e25b84f1eb@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tuesday 26 May 2009 2:41:03 pm Kip Macy wrote: > ter. > > > > Umm, that doesn't help. Your kthread's main routine is "physically" located > > in your kld. It needs to get into the text of kthread_exit() before it is > > safe for your module to unload, and so you have to sleep on the kthread/kproc > > pointer to wait for the wakeup in kthread_exit() to fire. You could have > > easily used msleep_spin() for this w/o hacking up condvar's to support spin > > locks too, FWIW. > > > > Good point. > > Which gets to my next question. Why is condvar preferred to msleep / > wakeup for everything BUT spin locks? This seems a bit hackish. Because too many people use spin locks. :) They are really only suitable for a limited set of problems, and many of those are for scheduler internals that don't use higher level primitives like sleep and wakeup. I can buy that pmc might be low-level enough to warrant use of a spin lock if you are interfacing with the NMI handler, but in that case I think msleep_spin() is probably sufficient for what you need. -- John Baldwinhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905261449.52153.jhb>