From owner-freebsd-threads@FreeBSD.ORG Sat Apr 26 05:24:36 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 D58DB37B401; Sat, 26 Apr 2003 05:24:36 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 246CC43FA3; Sat, 26 Apr 2003 05:24:35 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h3QCOXUp051035; Sat, 26 Apr 2003 05:24:34 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <004001c30bef$648ff0b0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: Date: Sat, 26 Apr 2003 20:28:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 12:24:37 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Saturday, April 26, 2003 12:52 PM Subject: Re: SMPing libpthread > On Thu, 24 Apr 2003, David Xu wrote: >=20 > > I have put a patch to enable userland support SMP scheduling.=20 > > http://people.freebsd.org/~davidxu/libpthread_smp.diff > > The patch works on my SMP machine, but not fully tested, > > and I will work on idle kses stuffs. At least, it seems > > the SMP speed is not slower than UP. :-) >=20 > David, I noticed that we hold the scheduling lock before and > after calling the scheduler. Is this necessary? And if so, > is it necessary to hold hold it after return from the > scheduling switch? One you're in the scheduler, and choose > another thread (releasing the lock after doing so), shouldn't > you be able to switch to it without having the lock? >=20 I am trying to do things in atomic way. because I found on SMP, thread state is always out of synchronized in current code. I want to make state change and context switch in an atomic operation, when thread is in state transit, no other threads can use _thr_setrunnable_unlocked() = etc to change its state, this avoids lots of "thread already in priority = queue" messages, and if I test the "in priority queue" flag every where, I = sometimes lose chance to wakeup a thread because of some unknown races, whole process just suddenly stops there. I am just copying the idea from current kernel code, I don't intend to = inventing new things. :-) One deadlock I found is in kse_sched_multi(), there is an optimization: if (curthread =3D=3D NULL) ; /* Nothing to do here. */ else if ((curthread->need_switchout =3D=3D 0) && (curthread->blocked =3D=3D 0) && (THR_IN_CRITICAL(curthread))) { /* * Resume the thread and tell it to yield when * it leaves the critical region. */ These code cause deadlock, at least there is a deadlock between = malloc/free and static mutex initializing code, I think unless we believe that thread = is locking a leaf=20 node, it is not safe to give cpu to the thread again. I suggest comment = out these=20 optimization code. I am still working on it, hope that I can post a patch soon. A bad news is kernel seems too unstable when testing KSE program, it = just silently locks up, not panic, no dump, just locks up, this is newest kernel = source code. :( > --=20 > Dan Eischen >=20 >=20