From owner-freebsd-current Tue Oct 20 09:33:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04706 for freebsd-current-outgoing; Tue, 20 Oct 1998 09:33:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from porkfriedrice.ny.genx.net (porkfriedrice.ny.genx.net [206.64.4.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04697 for ; Tue, 20 Oct 1998 09:33:35 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by porkfriedrice.ny.genx.net (8.9.1/8.9.1) with ESMTP id MAA28941; Tue, 20 Oct 1998 12:35:14 -0400 (EDT) (envelope-from bright@hotjobs.com) X-Authentication-Warning: porkfriedrice.ny.genx.net: bright owned process doing -bs Date: Tue, 20 Oct 1998 12:35:14 -0400 (EDT) From: Alfred Perlstein X-Sender: bright@porkfriedrice.ny.genx.net To: HighWind Software Information cc: current@FreeBSD.ORG Subject: Re: Another Serious libc_r problem In-Reply-To: <199810201618.MAA26576@highwind.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hmmm, a better idea would be for queues to remeber how many elements are on them, that way a malloc could have been done, either that or the scheduler should be able to accept a queue of threads to schedule, but that would require a lot of work. btw, the patch I do isn't anything spectacular it just avoids looping and spinlocking, if you apply the patch and time a much longer loop in the main thread, 6,000,000 iterations vs 12 and removed the select calls you should see some improvement in the execution time. The problem with all these patches is that the even the ones that address broadcasts (which don't work to begin with) do not make it an atomic operation. (where it was in theory before, but didn't work) As a side note, has anyone thought of hybrid kernel+userland threads? Basically a userland scheduler with kernel hooks for mutexes and distributing signals. At startup or on the first pthread_create() the pthreads library would sysctl out the number of processors in the system and prefork kernel threads for each. The kernel threads would only be active on SMP machines, otherwise there really is no point. Does anyone have any papers/webpages about an algorithm like that? Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current On Tue, 20 Oct 1998, HighWind Software Information wrote: > > Hmmm. Now we got 3 patches. > > I am a little wary about Alfred's "broadcast" patch. Seems premature > optimization. I'd rather have something that is conservative first. > > Can someone with commit priviledges take a peek at this and add one > of these to the source? > > -Rob > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message