From owner-freebsd-threads@FreeBSD.ORG Mon Apr 26 10:38:11 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7865E16A4CE; Mon, 26 Apr 2004 10:38:11 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 289B043D5E; Mon, 26 Apr 2004 10:38:11 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i3QHc9Qk010299; Mon, 26 Apr 2004 13:38:09 -0400 (EDT) Date: Mon, 26 Apr 2004 13:38:09 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: John Baldwin Subject: Re: kse_release and kse_wakeup problem (fwd) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 17:38:11 -0000 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). -- Dan Eischen