Date: Mon, 07 Jan 2002 01:07:32 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jake Burkholder <jake@locore.ca> Cc: Bernd Walter <ticso@cicely8.cicely.de>, Alfred Perlstein <bright@mu.org>, Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <3C396554.9B6A9053@mindspring.com> References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> <20020107015228.E39321@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Jake Burkholder wrote: > > > > > Is there a reason that getcontext and setcontext need to be > > > > > system calls? > > > > Atomicity? > > > To flush register windows on setcontext() on SPARC. > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > > mit-pthreads use it from userland. > > Yes, this (flushw) is the best way to flush the windows on v9 at least. > > > > > Are there any performance reasons to flush windows in kernel? > > No, doing so is actually more complicated (slightly) due to having > to use copyout and due potentialy having to deal with 32bit applications > running on 64bit kernels. It is easier if the spills look like normal > spills. The "flushw" is not enough. The following paper discusses the original implementation of the "liblwp" code on SunOS 4.x: http://www.cs.washington.edu/research/compiler/papers.d/thread-regwin.html Here, if you are allergic to PostScript, and want a PDF or other format: http://citeseer.nj.nec.com/keppel91register.html -- Multiple lightweight processes or threads have multiple stacks, and a thread context switch moves execution from one stack to another. On the SPARC architecture, parts of a thread's stack can be cached in register windows while the thread is running. The cached data must be flushed to memory when the thread is suspended. Doing the flushing both efficiently and correctly can be tricky. This document discusses the implementation of a non-preemptive user-space threads package under SunOS. %A David Keppel %A Register Windows and User-Space Threads on the SPARC %R UWCSE 91-08-01 %I University of Washington Department of Computer Science and Engineering %D August 1991 -- See also: http://citeseer.nj.nec.com/15548.html The basic problem is that stack is cached in registers, not flushed to RAM, and you may be resuming on another processor while another one still hasn't written the register caches back so that the memory image you load on the new processor is valid. -- Terry 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?3C396554.9B6A9053>