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>
index | next in thread | previous in thread | raw e-mail
> > > 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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15422.7120.512072.974803>