From owner-freebsd-arch Tue Nov 2 20:25:10 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 031E614C39 for ; Tue, 2 Nov 1999 20:25:06 -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 FAA02923 for ; Wed, 3 Nov 1999 05:25:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA84281 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 05:25:05 +0100 (MET) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id DC98E154D6 for ; Tue, 2 Nov 1999 20:24:26 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id UAA29559; Tue, 2 Nov 1999 20:24:25 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id UAA47266; Tue, 2 Nov 1999 20:24:25 -0800 (PST) (envelope-from jdp@polstra.com) Date: Tue, 2 Nov 1999 20:24:25 -0800 (PST) Message-Id: <199911030424.UAA47266@vashon.polstra.com> To: eischen@vigrid.com Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> References: <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <381F85F2.BF6D5A2@vigrid.com>, Daniel M. Eischen wrote: > Nate Williams wrote: > > > > > 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. I think the "delimiting, with special assembler labels" is simply the addition of some asm statements to the C source code of their libc_r threads kernel equivalent. The second part, "post-process the compiler-generated assembly code," is just a little program or shell/awk/sed/perl script and some fancy Makefile rules. 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. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message