From owner-freebsd-arch Fri Sep 20 12:12:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA8E37B404 for ; Fri, 20 Sep 2002 12:12:50 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0875943E42 for ; Fri, 20 Sep 2002 12:12:50 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id BE52AAE162; Fri, 20 Sep 2002 12:12:44 -0700 (PDT) Date: Fri, 20 Sep 2002 12:12:44 -0700 From: Jon Mini To: Terry Lambert Cc: Daniel Eischen , Bill Huey , freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model Message-ID: <20020920191244.GY24394@elvis.mu.org> References: <3D8B62DB.C27B7E07@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B62DB.C27B7E07@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message