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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 26 May 2009 2:41:03 pm Kip Macy wrote: > ter. > > > > Umm, that doesn't help. =A0Your kthread's main routine is "physically"= =20 located > > in your kld. =A0It 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=20 kthread/kproc > > pointer to wait for the wakeup in kthread_exit() to fire. =A0You could = have > > easily used msleep_spin() for this w/o hacking up condvar's to support= =20 spin > > locks too, FWIW. > > >=20 > Good point. >=20 > 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 f= or=20 a limited set of problems, and many of those are for scheduler internals th= at=20 don't use higher level primitives like sleep and wakeup. I can buy that pm= c=20 might be low-level enough to warrant use of a spin lock if you are=20 interfacing with the NMI handler, but in that case I think msleep_spin() is= =20 probably sufficient for what you need. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905261449.52153.jhb>