Date: Mon, 28 Jan 2002 11:27:44 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, <arch@FreeBSD.ORG> Subject: Re: KSE question Message-ID: <20020128111527.N40006-100000@gamplex.bde.org> In-Reply-To: <3C51EC04.D99E8491@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2002, Terry Lambert wrote: > The worst case scenario is: > > 1) Multithreaded program on SMP system > 2) FPU thread runs on CPU #1 and causes, but does not > reap exception > 3) Non-FPU thread runs on CPU #1 > 4) Original FPU thread resumes running on CPU #2; no > exception is correctly signalled Actually: 4) Original FPU thread resumes running on CPU #2; exception is correctly signalled (i.e., not yet). at least for non-broken i386's. For broken i386's (ones with a separate FPU or ones with a backwards bug-for-bug-compatibility mode enabled): 3a) Saving state for FPU thread causes bogus exception in the context of the non-FPU thread (actually in the context switcher if the context switcher waits a bit); context switcher knows that it is bogus and ignores it. 4a) Restoring state for FPU thread causes bogus exception in the context of the FPU thread (actually in the context switcher); context switcher knows that it is bogus but (as far as I can see) can't signal it correctly (i.e., not yet). > If there's a flaw in my reasoning, I'd be happy to have it > pointed out to me... The unreaped exception is part of the FPU state (at least on i386's). Bruce 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?20020128111527.N40006-100000>