Newsgroups: comp.lang.lisp.mcl
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!news-peer.gsl.net!news.gsl.net!www.nntp.primenet.com!nntp.primenet.com!nntp.uio.no!voskovec.radio.cz!btnet-feed2!unlisys!cs.tu-berlin.de!news.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: multiprocessing support
Message-ID: <1996Dec18.102731.15243@wavehh.hanse.de>
Reply-To: cracauer@wavehh.hanse.de
Organization: Private site
References: <duff-ya023480001312960214280001@news>
Date: Wed, 18 Dec 96 10:27:31 GMT
Lines: 79

duff@mitre.org (David Duff) writes:

>i have no particular reason besides curiosity at this point for asking this
>question...  

>but now that there are relatively inexpensive macs with multiple
>processors, processor add-in cards, and such, and an official apple-blessed
>interface for dealing with them, i was wondering if anyone has considered
>multiprocessor support for mcl. 

I've been looking into the issues involved when running Lisp processes
on different OS threads.

First of all, while I don't know the Macintosh thread system, the
existing OS thread interfaces I know of are insufficient to support
thread in a garbage-collected language that manages stacks on its own.

The only way I see to do so is to use an operating system call like
rfork() (plan9, FreeBSD) or clone() (Linux) that creates a new
sheduled process on OS level that has its address space shared with
other processes. The whole synchronisation stuff must be rewritten in
the Lisp implementation, I see no way to use existing userlevel thread
libraries.

You may read some of my thoughts (no, its not more than thoughts :-)
at
http://www.cons.org/cracauer/lisp-threads.html

[...]
>you might add a few simple language constructs (macros) for performing
>tasks in parallel - e.g., (par <form> <form> <form> ...).   i think these
>kinds of things have already been worked out for earlier experimental
>extensions of lisp for parallel machines (star-lisp for the connection
>machine, perhaps?  or wasn't there a parallel lisp that ran on the bbn
>parallel machine?)

As you say, once you have Lisp threads/processes running on different
OS-sheduled entries, this is just a matter of syntactic sugar on top
of existing Lisp thread APIs.

[...]

>i'm not claiming to be any kind of expert on parallel processing - rather i
>suspect that there are lots of other people out there who have already
>thought deeply about these issues.   for example, i wonder if it would be
>possible to have gc work be done by a separate scavenger process...

The last issue is one of the most difficult things to do.

Under normal circumstances, you have to stop all other threads (no
matter whether they run on different processors) before doing
GC. Otherwise, you'll garbage collect a moving target. Some
incremental GC techniques already trace memory allocation in a way
that can be used to do solve this problem, but this is definitivly too
complex for me.

Currently, the options I see to get a Lisp speaded over multiple
processors are:
- Create a new OS level process with its own address space and define
  some syntactic sugar to define variable that behave like shared
  ones. CMUCL already does this.
- Use rfork/clone calls and steal synchronisation code from userlevel
  libraries with source (i.e. Linuxthreads).

In practice, my effort is stalled because CMUCL is the only free
compiler worth parallelizing (what's the sense in spreading a Lisp
system over 4 processors if the code is 10 times as inefficient as a
compatible implementation?). CMUCL is complex enough to keep me
standing still.

As I said, I don't know about the Mac thread support and the MCL
thread interface.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org  Fax.: +4940 5228536
"As far as I'm concerned,  if something is so complicated that you can't ex-
 plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
