From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 22:40:55 2003 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 5F92C37B401; Sat, 5 Apr 2003 22:40:55 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0EE543FAF; Sat, 5 Apr 2003 22:40:54 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h366epBg025736; Sun, 6 Apr 2003 01:40:51 -0500 (EST) Received: from localhost (eischen@localhost)h366epGx025729; Sun, 6 Apr 2003 01:40:51 -0500 (EST) Date: Sun, 6 Apr 2003 01:40:50 -0500 (EST) From: Daniel Eischen To: DavidXu In-Reply-To: <002c01c2fbec$b23756e0$0701a8c0@xu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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: Sun, 06 Apr 2003 06:40:55 -0000 On Sun, 6 Apr 2003, DavidXu wrote: > Daniel, > > I saw your code in thr_kern.c assumes that a blocked thread > in kernel will always be returned in same upcall(your userland > kse)? However, current kernel will returned this context in one > of upcall in the same ksegrp, so there is race in your code, > I think this may be a kernel bug but not yours, this does not > very respects original paper. Hey, glad to see you got through to an @freebsd.org list from home (I presume)! Actually, I got rid of PS_BLOCKED earlier today. I think I deal with blocked threads OK now and I don't think I assume (any longer) that they belong to any particular KSE. I've made some decent progress and can run the mutex test sucessfully, and can run most of the ACE tests also. Some of the ACE tests fail, but some also fail with libc_r (I don't think it's the threads library). I'm running them with libc_r now and will compare against libkse. I've still got one bug I am trying to hunt down with signals -- the sigwait test fails. Process (kill) signals don't seem to wakeup threads in sigwait(). I'm not sure if it is a kernel bug or not, but I suspect it's something I'm doing. One question. What happens when kse_release(tsp) is called when k_mbx.km_curthread == NULL? Does it just return after the timeout, or is there a new upcall? And if kse_A->k_mbx.km_curthread == NULL and it is in a kse_release(tsp), can another kse interrupt it (before the timeout) with kse_wakeup()? -- Dan Eischen Let's Go Orange!