Date: Mon, 26 Apr 2004 10:55:39 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: David Xu <davidxu@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: kse_release and kse_wakeup problem (fwd) Message-ID: <Pine.GSO.4.10.10404261047480.19899-100000@pcnet5.pcnet.com> In-Reply-To: <408D0373.8050006@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Apr 2004, David Xu wrote: > John Baldwin wrote: > > > > > > I.e. do the upcall check in sleepq_catch_signals() right where you already do > > thread_suspend_check(1). The only reason you have to do this, btw, is > > because the kse_release() code is trying to mess with thread state internals > > using sleepq_abort(), etc. The other in-kernel code that does that (signals) > > already does the check in sleepq_catch_signals() and has done the same type > > of check in msleep()/tsleep() for quite a while. > > > > If the kse_release() stuff was just using sleep/wakeup() rather than trying to > > manually abort sleeps it wouldn't have to be so intimate with the sleep > > interface. > > > > Note that thr's thr_wakeup() and thr_sleep() manage to simulate > > synchronization w/o having to abort sleeps, but it is probably also easier to > > do that than for the M:N case. > > > > I think libthr will encounters same problem as libpthread with new sleep > queue code, because mtx is released too early in msleep before thread > markes itself as ON_SLEEPQ, thr_suspend and thr_wakeup have same race > window as kse_release and kse_wakeup. Any code wants to put synchronous > bit in td_flags like these codes will be broken. I'm experimenting with adding an wakeup_thread() to kern_thread.c (to complement wakeup() and wakeup_one()). If we shouldn't be using sleepq's directly, the thread code either needs to a) queue msleep()'ing upcalls/threads itself having them all block on on their own unique wchan's; or b) use a wakeup_thread() that wakes up a specific thread. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404261047480.19899-100000>