Date: Tue, 27 Apr 2004 07:30:06 +0800 From: David Xu <davidxu@freebsd.org> To: Daniel Eischen <eischen@vigrid.com> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: kse_release and kse_wakeup problem (fwd) Message-ID: <408D9B7E.2080804@freebsd.org> In-Reply-To: <Pine.GSO.4.10.10404261329260.1789-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10404261329260.1789-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Mon, 26 Apr 2004, Daniel Eischen wrote: > > >>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. > > > Sorry, patch for b) is at: > > http://people.freebsd.org/~deischen/sys.diffs > > I don't like using upcall flags, though. It seems to require taking > the scheduler lock to fiddle with them and that adds some overhead. > Perhaps add another field so we only need to use the proc lock. > > There was also a bug in kse_release() where wakeup_one() is called > with the sched_lock held (fixed in above patch). > The patch is fine for me. if you don't like sched_lock, you can create another field and use proc lock. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?408D9B7E.2080804>