From owner-freebsd-threads@FreeBSD.ORG Fri Jul 9 03:50:58 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 1935E16A4CE for ; Fri, 9 Jul 2004 03:50:58 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5103643D45 for ; Fri, 9 Jul 2004 03:50:57 +0000 (GMT) (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 i693n6fP028381; Thu, 8 Jul 2004 23:49:06 -0400 (EDT) Date: Thu, 8 Jul 2004 23:49:06 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Andrew Gallatin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread switch (was Odd KSE panic) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2004 03:50:58 -0000 On Tue, 6 Jul 2004, Daniel Eischen wrote: > On Tue, 6 Jul 2004, Andrew Gallatin wrote: > > > > > > does your worker thread loop to check if there is more work before > > > waiting to be notified? > > > > Yes. He takes a mutex, loops over all completed events, sending > > pthread_signals as required, then releases the mutex and sleeps via > > an ioctl. > > Note that he is holding the mutex while calling pthread_cond_signal(). > If we enable preemption in pthread_cond_signal(), then I suspect it > would be even worse than without preemption. > > I think the only place where it is sane to enable preemption is > on pthread_mutex_unlock(). Wewll, I just took a look at this. I had already added a preemption point in pthread_mutex_unlock(): $ cvs log -r1.38 lib/libpthread/thread/thr_mutex.c ... description: ---------------------------- revision 1.38 date: 2003/07/18 02:46:29; author: deischen; state: Exp; lines: +10 -6 Add a preemption point when a mutex or condition variable is handed-off/signaled to a higher priority thread. Note that when there are idle KSEs that could run the higher priority thread, we still add the preemption point because it seems to take the kernel a while to schedule an idle KSE. The drawbacks are that threads will be swapped more often between CPUs (KSEs) and that there will be an extra userland context switch (the idle KSE is still woken and will probably resume the preempted thread). We'll revisit this if and when idle CPU/KSE wakeup times improve. Note that the priority of a runnable thread must be strictly greater than the currently running thread in order for preemption to occur. -- Dan Eischen