From: Anthony Green
Subject: Summary: LISP with threads (REPOST)
Date:
Message-ID: <742315656snx@roboco.UUCP>
Here is a summary of responses to my "Threaded LISP" query of July 4.
First, thanks goes to Thomas M. Breuel (···@idiap.ch) for pointing out that..
> "Threaded LISP" is not the same as "LISP with threads". "Threaded" is
> a particular style of implementation, commonly used with FORTH.
He, as with many respondants, mentions that most commercial CL implementations
support threads. Also...
> I'd suggest taking a look at Abelson and Sussman's "Structure and
> Interpretation of Computer Programs", and playing around with a
> CommonLisp implementation that supports threads.
David Gadbois (·······@cs.utexas.edu) says...
> Symbolics, Allegro, and Lucid Common LISPs all have multithreading
> facilities. They all call them "multiprocessing" facilities, which is
> somewhat confusing in today's terminology since the standard
> definition of a process usually includes having a separate address
> space. I am told that Harlequin CL also has such a facility. In
> contrast, CMU CL has "heavyweight" UNIX processes.
>
> The solution to your Big Problem in all of them is a notion of a
> "standard binding." Conceptually, each thread starts out with a
> standard value for important global variables like *PACKAGE*,
> *PRINT-PRETTY*, and whatnot, so that if the program sets the value of
> one of these, it affects only the binding and not the global, standard
> value. There are ways to add and change standard bindings. This
> approach works quite well in practice.
>
> The biggest gotcha for me is the IO interface. In Lucid CL, threads
> default to sharing a single IO stream, and it can be a real bother to
> debug situations in which more than one thread is going for input on
> the same stream. Symbolics CL associates a "background window" with
> threads that do not have interactive streams bound to the stream
> variables. This problem is pretty universal for any multithreading
> system, but it seems more prominent in CL since it is so easy to do
> interactive IO.
>
> I wish there would be some standardization on CL multithreading. It
> is a really crucial abstraction for hairy user interfaces and
> client/server architectures. The three implementations I mentioned
> are all sufficiently similar that it is easy to come up with a
> standard interface to them, but some CL's just do not have the
> infrastructure in place. (The implementation of a multithreading
> facility has pretty deep implications all over the system, so it is
> not something that can be added in easily or as a user-level package.)
> Kent Pittman had sent in a comment to the X3J13 ANSI CL
> standardization committee that proposed a multithreading facility, but
> it looks like it is too late in the standardization game for it to go
> through.
Suresh Jagannathan (······@research.nj.nec.com) replied with...
> I saw your posting on comp.lang.lisp re. threaded Lisp systems.
> You may be interested in two papers that appeared in the 1992
> PLDI and L&FP proceedings on Sting, a customizable, multi-threaded
> dialect of Scheme. Here's an abstract:
>
> -----------------------
>
> We have built a parallel dialect of Scheme called Sting that differs
> from its contemporaries in a number of important respects. Sting is
> intended to be used as an operating system substrate for modern
> parallel programming languages.
>
> The basic concurrency management objects in
> Sting are first-class lightweight threads of control and virtual
> processors (VPs). Unlike high-level concurrency structures, Sting
> threads and VPs are not encumbered by complex synchronization
> protocols. Threads and VPs are manipulated in the same way as any
> other Scheme structure.
>
> Sting separates thread policy decisions
> from thread implementation ones. Implementations of different
> parallel languages built on top of Sting can define their own
> scheduling and migration policies without requiring modification to
> the runtime system or the provided interface. Process migration and
> scheduling can be customized by applications on a per-VP basis.
>
>
> The semantics and implementation of threads minimizes the cost of
> thread creation, and puts a premium on storage locality. The storage
> management policies in Sting lead to better cache and page
> utilization, and allows users to experiment with a variety of
> different execution regimes -- from fully delayed to completely eager
> evaluation.
>
> Sting is not only intended to be a vehicle that implements stand-alone
> short-lived programs. We envision Sting as providing a framework in
> which to build a rich programming environment for parallel symbolic
> computing. In this regard, the system provides support for thread
> preemption, per-thread asynchronous garbage collection, general
> exception handling across thread boundaries, and non-blocking I/O. In
> addition, it contains the necessary functionality to handle persistent
> long-lived objects, multiple address spaces and other features
> commonly associated with advanced programming environments and
> operating systems.
I am interested in reading Kent Pittman's X3J13 multithreading proposal.
Is Kent on the Net?
In a recent comp.object post, Paul Johnson (···@gec-mrc.co.uk) states that...
> Most GCs these days are
> incremental, running in parallel with the program rather than stopping
> it for five seconds every few minutes.
Is this true of the CL implementations that support threads? I see from the
above abstract that Sting has anychronous GC.
I will be contacting the major LISP vendors for information on thread support
in their packages. I also dug this up from the LISP FAQ:
Feel (Free and Eventually Eulisp) is an initial implementation of the
EuLisp language. It can be retrieved by anonymous FTP from
ftp.bath.ac.uk in the directory /pub/eulisp/ as the file
feel-0.75.tar.Z.
<info deleted here>
It includes an integrated object system, a module system, and support
for parallelism
^^^^^^^^^^^ It goes on to talk a bit about thread support for various
machines.
I'm going to have a good look at EuLisp this week.
Thanks to all who replied!
Anthony
NOTE: Please send mail to ·············@utai.toronto.edu".
--
Anthony T. Green 343D St. Clair Ave W, Toronto, Ontario M5P 1N3
Home (416) 968-0817 Internet: ············@utai.toronto.edu
Office (416) 340-0887 UUCP : ...!uunet!utai!roboco!green
Hello,
> Kent Pittman had sent in a comment to the X3J13 ANSI CL
> standardization committee that proposed a multithreading facility, but
> it looks like it is too late in the standardization game for it to go
> through.
Is Kent Pittman's document available anywhere?
Thanks
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht