Date: Wed, 3 Nov 1999 08:03:20 -0700 From: Nate Williams <nate@mt.sri.com> To: John Polstra <jdp@polstra.com> Cc: eischen@vigrid.com, arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <199911031503.IAA08453@mt.sri.com> In-Reply-To: <199911030424.UAA47266@vashon.polstra.com> References: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com> <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> <199911030424.UAA47266@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911031503.IAA08453>