From owner-freebsd-threads@FreeBSD.ORG Sat Apr 26 11:09:29 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 D25B337B401; Sat, 26 Apr 2003 11:09:29 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11FF543FBF; Sat, 26 Apr 2003 11:09:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0174.cvx40-bradley.dialup.earthlink.net ([216.244.42.174] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 199U74-000245-00; Sat, 26 Apr 2003 11:09:27 -0700 Message-ID: <3EAACB08.BFD0B8F5@mindspring.com> Date: Sat, 26 Apr 2003 11:08:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4725a00e406b7611270dcb04c44f550ae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread 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: Sat, 26 Apr 2003 18:09:30 -0000 Daniel Eischen wrote: > On Thu, 24 Apr 2003, David Xu wrote: > > I have put a patch to enable userland support SMP scheduling. > > 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. :-) > > 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? IMO, this depends entirely on the scheduler in question; this is something Jeff and Julian were working on divorcing from the threads API entirely, and putting into a scheduler API that was supposed to be seperate and deal with policy issues like scheduling locks. It's very easy to envision an SMP scheduler that has zero locks, for example, so holding a lock in threads code before calling into the scheduler API would not only be counter-productive, it would be referencing a non-existant lock. Jeff and Julian probably have more to say on their implementation ideas. -- Terry