Date: Thu, 10 Jan 2002 15:55:12 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15422.7120.512072.974803@caddis.yogotech.com> In-Reply-To: <3C3E168B.B768CDC8@mindspring.com> References: <Pine.SUN.3.91.1020110161827.1485C-100000@pcnet1.pcnet.com> <3C3E168B.B768CDC8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Type slowly, I'm old, and other people on this list are older... > > > > > > What problem? > > > > > > If signal code doesn't touch the FPU statem then it's totally > > > transparent to the lazy save of FPU context state. > > > > OK, so the signal handler saves the interrupted context > > and resumes/starts another context. With me so far? > > Yes. > > > Perhaps a few contexts later, and perhaps even a few > > signals later, > > Still with you... > > > and after doing some additional floating point stuff, > > Bzzt! OK, how does this "additional floating point stuff" > happen? I see exactly two cases: > > 1) It is the first occurance of floating point in the > context; this is complicated. It's actually not complicated. It can be treated as a completely separate context (in a separate thread, or whatever). > 2) It is an occurance subsequent to the first in the > context, in which case, when the context was brought > back, the state was brought back, as well, so it's > already dealt with, since the previous context > could have been lazy-save at that point. Daniel's example stated it wasn't in the same context, hence the need to restore the old (prior) context that was saved. > My answer to #1 is to treat the FP context as being "per > process", rather than "per thread", and then do explicit > (non-lazy) saves _only_ when migrating between CPUs. But, Terry. The context is per-thread. You can't treat as a per-process context, becuase there *are* multiple contexts (threads) per process, and each of these context has (the potential) to have separate FPU context. This is just the way it is, like it or not. Here's a *very* simple Java example. class FPUExample extends Thread { public static void main(String args[]) { Thread one = new Thread(new FPUExample(++threadCount)); Thread two = new Thread(new FPUExample(++threadCount)); one.start(); two.start(); try { one.join(); two.join(); } catch (InterruptedException e) { // Ignored } } static int threadCount = 0; int myThreadNum; FPUExample(int _myThreadNum) { myThreadNum = _myThreadNum; } public void run() { System.out.println("Starting Thread" + myThreadNum); for (int i = 0; i < 10; i++) { double dbl; dbl = (double)i + 1.0; System.out.println("T#" + myThreadNum + " num=" + dbl); // This works better than Thread.yield() try { Thread.sleep(1); } catch (InterruptedException e) { // Ignored } } } } This java program runs under FreeBSD as a single process, but has two different thread contexts that do FPU operations. > It's tempting to say that the FPU enable/disable (and therefore > the save/restore) should be a system call, and handled on a per > thread basis by the user space scheduler. If the FPU is used, > then you pay an extra system call per context switch penalty > in the user space scheduler for the use of it. This conflicts with what you are saying above, because each 'thread' is a different context in the same process. 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?15422.7120.512072.974803>