[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multithreaded Common Lisps
Date: Thu, 9 Mar 89 21:27:01 EST
From: Phil Dykstra <phil@BRL.MIL>
I was glad your note did go to cl-windows, I found the DELPHI common lisp
remarks interesting. You mentioned that it had:
- Multithread support for concurrency. The Multithread
primitives can also be used to implement semaphores, OCCAM
channels and other typical concurrency schemes. A small
amount of code can be written to emulate efficiently
the concurrency metaphors of other Lisps. Delphi has
already implemented extensions to CLOS to allow the definition
of concurrent synchronizable atomic methods.
Is there some emerging standard or proposed standards for concurrency
control in Common Lisp? I was toying with adding such to AKCL but I
would rather not make up my own interface if there's an accepted one
This may be a little off topic for cl-windows, but multi-thread
support is very handy for event driven window interfaces. The MCC
DELI Window System interface (no relation to DELPHI) relies heavily on
multi-threading above the retagetable Window System Independent
Most of the compiler vendors seem to be using the same stack group
based model found in the MIT Lisp Machine and descendants. Lucid
doesn't export their stack groups, but the multi-thread interface is a
bare bones version of the MIT support, Franz Allegro has very closely copied
the Lisp Machine interface. I understand that Gold Hill has stack
group support - so the multi-thread interface should be easy to write.
KCL has been a noteable exception, which is one reason why DELPHI was
of interest. The Xerox Interlisp based machines used a different
model - the spaghetti stack. At MCC we wrote a multi-thread interface
module which paper over the syntactic differences between the
Symbolics, Lucid, and Franz Allegro compiler multi-thread interfaces.
Unfortunatly we chose a slightly different syntax from the MIT Lisp
Machine. I don't have a details on what DELPHI has done, but I would
recommend the MIT semantics and syntax because:
1. A large body of existing code uses it (ie any multi-process code
written for MIT flavor lisp machines).
2. Already supported by multiple vendors (Franz, LMI/Gigamos,
Symbolics, and TI with Lucid using the same semantic model).
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: email@example.com PHONE: (512) 338-3533