Date: Fri, 20 Sep 2002 12:12:44 -0700 From: Jon Mini <mini@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Bill Huey <billh@gnuppy.monkey.org>, freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model Message-ID: <20020920191244.GY24394@elvis.mu.org> In-Reply-To: <3D8B62DB.C27B7E07@mindspring.com> References: <Pine.GSO.4.10.10209200002280.2162-100000@pcnet1.pcnet.com> <3D8B62DB.C27B7E07@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert [tlambert2@mindspring.com] wrote :
> I am not personally familiar with the FreeBSD scontext(2) call
> that has been discussed as an implementation detail with regard
> to some of the recent postings by Daniel Eischen, in which he
> implied Jonathan Mini will be implementing the call.
It's not scontext(2), but setcontext(2) -- of Solaris fame. Currnetly,
we have {get,set,swap}context(3), but being in userland causes some
interesting race conditions. Really, these functions needs to be
atomic from the process's perspective, and since they have to call
sigprocmask(2) anyways, the best solution is to just move them into
the kernel. This is how Solaris does it, among others.
> Perhaps I
> should have been watching this more closely, so that I could
> comment more intelligently on what it's supposed to do for the
> FreeBSD implementation which can not be done without: the Linux
> people may have a valid argument here which FreeBSD should heed.
> However... such a call is necessary to deal with register windows
> on SPARC processors, in any case, and the implementation is moot
> by way of the fact that trading a user context switch plus a
> kernel call for a kernel context switch hardly reduces overhead.
Under KSE, we needn't consult the kernel for thread context swaps,
because we can enter a critical section and avoid the race conditions
endemic with setcontext(2). Also, we don't modify the process signal
mask when we swap thread contexts, so we don't need to call
sigprocmask(2).
> I think the "the Linux scheduler is O(1), so we don't have to
> care" argument is invalid; O(1) means that for N entries, there
> need to be N elements traversed 1 time. What this really means
> is that, as the number of schedulable entitites goes up, the time
> required goes up linearly, as opposed to going up exponentially;
> or, better, to *not* going up in the first place.
Terry? You must have misspoken here. O(N) is linear, O(1) is constant.
> One exception is the use
> "futex" wakeup in order to improve thread joins: FreeBSD should
> look closely at this.
"Futexes" are not new. We had this at Be, but we called them Bennaphores.
--
Jonathan Mini <mini@freebsd.org>
http://www.freebsd.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020920191244.GY24394>