Date: Sat, 26 Apr 2003 11:08:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread Message-ID: <3EAACB08.BFD0B8F5@mindspring.com> References: <Pine.GSO.4.10.10304260043470.25254-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EAACB08.BFD0B8F5>