Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Oct 1998 12:35:14 -0400 (EDT)
From:      Alfred Perlstein <bright@hotjobs.com>
To:        HighWind Software Information <info@highwind.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: Another Serious libc_r problem
Message-ID:  <Pine.BSF.4.05.9810201223390.18282-100000@porkfriedrice.ny.genx.net>
In-Reply-To: <199810201618.MAA26576@highwind.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9810201223390.18282-100000>