On 28-Mar-08, at 5:29 PM, Elliott Slaughter wrote:
> I am applying for Google Summer of Code and I am wondering what
> exactly is involved in the win32 threads project. (I know the CLISP
> threading project is considered very difficult because CLISP has not
> yet dealt with general issues of concurrency. I suspect SBCL has
> already dealt with these because it has threads on at least some
> platforms, but I don't really know.)
Alastair Bridgewater (who got the ball rolling on the win32 port)
kindly provided the following summary (also available at <http://paste.lisp.org/display/58376
>) of what needs to be done to hack threads in sbcl/win32. It should
give you a decent idea of the amount of work the task represents.
Someone on the CLISP mailing list might be able to offer similar
advice, which would let you make a better informed project proposal.
> As of right now (31 Mar 2008), so far as I'm aware, the following is
> the status on SBCL Win32 threading.
> 1.) There is a patch set for scaring up an extra register to use
> for a TLS block (necessary on Win32, due to various OS
> limitations). The patches are available at <http://www.lisphacker.com/temp/sbcl-ebx-threads/
> >, but you won't need them.
> 2.) There is a patch that contains the ebx-threading patches
> mentioned above as well as all the requisite damage to at least -
> create- a thread. This is available at <http://www.lisphacker.com/temp/wthread-combined-1a.diff
> >. The patch is just over a year old now (24 Mar 2007). You can
> see some session transcripts from using this patch at <http://paste.lisp.org/display/38635
> >. This is where I left off.
> 3.) What needs doing:
> a.) Forward port wthread-combind-1a.diff from 184.108.40.206 to HEAD,
> or at least the latest release. This may require some VOP (assembly-
> level) hacking if things have drifted too far over the past year.
> It shouldn't be too bad, and there are a few people who would be
> able to help out here. Also note that the VOP fixing can be done on
> a Linux host instead of a Win32 one (there's a combination of target
> features that builds an x86/Linux SBCL in ebx-thread mode).
> b.) Lisp-level thread synchronization. This would probably be
> lutexes or similar.
> c.) Stopping the world for GC. SBCL's garbage collector needs
> must stop every "mutator" (lisp) thread in order to do a GC. This
> leads to questions of when it is safe to stop a thread, even
> temporarily (can't stop one for long in pseudo-atomic, for example,
> and stopping one in alien code might be risky). The GC also needs
> access to the thread's register context. For every thread,
> gc_stop_the_world() must suspend the thread, check to see if it can
> be safely stopped, and, if not, needs to resume it briefly. Once a
> thread is stopped, its register information must be put where the GC
> can find it. gc_start_the_world() can probably get away with just
> resuming all of the threads.
> d.) Interrupt-thread. This is closely related to stopping the
> world. Essentially, you have to suspend a thread that is in an
> interruptable state (whatever -that- is, given that interrupt-thread
> is inherently unsafe), force a new function call frame on the stack,
> possibly with a dummy frame with register context information and
> pointing to a trampoline to restore such, and resume the thread.
> e.) Make sure the system is stable. Threading support, even
> after it is basically working, has been nasty to get working stably
> on each new platform it is introduced on. We have horror stories.
> f.) Watch for resource leaks. It's bad enough we leak file
> descriptors, but what if we leak a small amount of address space per
> thread, even after they've finished running?
> Things that you will need to know or learn in order to implement all
> this include but are not limited to: x86 assembly language, x86 sbcl
> calling conventions, win32 synchronization apis, and win32 thread
> I think that's everything. It's at least everything for now.
> -- Alastair Bridgewater