From owner-freebsd-arch Wed Nov 3 7: 3:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0C96014C4C for ; Wed, 3 Nov 1999 07:03:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA11872 for ; Wed, 3 Nov 1999 16:03:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA87336 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 16:03:34 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id CE72C14C4C for ; Wed, 3 Nov 1999 07:03:24 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA11806; Wed, 3 Nov 1999 08:03:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA08453; Wed, 3 Nov 1999 08:03:20 -0700 Date: Wed, 3 Nov 1999 08:03:20 -0700 Message-Id: <199911031503.IAA08453@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Polstra Cc: eischen@vigrid.com, arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <199911030424.UAA47266@vashon.polstra.com> References: <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> <199911030424.UAA47266@vashon.polstra.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > For a thread bound to a LWP, you only notify the user level threads > > > > library if it blocks because it's time quantum expired (so the threads > > > > library can see if it is in a critical region). > > > > > > They talk about this in the paper, and I don't like their solution. > > > Having to modify the compiler/assembler and such is not a workable > > > solution, IMO. > > > > No, I didn't either, but you can still get the same thing by manually > > coding each routine. You could also set flags instead with not too > > much more overhead. > > I've just been looking at the paper, and I don't think they modified > the compiler or the assembler. What they say is: > > We do this by delimiting, with special assembler labels, each > critical section in the C source code for the user-level thread > package; we then post-process the compiler-generated assembly > code to make the copy. Correct, but right after that, they stated that instead of having to specially annotate critical sections with assembler labels, it could be picked up automatically with the use of a modified compiler/assembler. Also, either way requires that the program be written in C/C++, which is unacceptable to me (and you I suspect), since some of my 'threaded' programs won't be written in C (Java) and you (Modula-3). These 'critical sections' will exist in Java, and I don't want to re-write the JVM to go figure out what sections are critical and have it build assembly versions. > All they are aiming for is a table of PC ranges that they can consult > at run time to determine whether the thread was in a critical section > when it blocked or was pre-empted. That's easy to get without > modifying the compiler or assembler -- especially with ELF, where we > can put the table into a separate section. See above. If the language you are using to write this stuff in isn't C/C++, it's not quite as straightforward. If you start coding anything that might be critical with the special assembly statements, you lose *much* (or all) of the performance gains that were given before since the VM can't differentiate between a 'critical' section of the code and a non-critical section of the code w/out alot of work, thus making many parts of the code 'critical' just in case. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message