Multithreaded Common Lisps

[Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>]

   Date:     Thu, 9 Mar 89 21:27:01 EST
   From: Phil Dykstra <phil@BRL.MIL>

   Rob,

   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
   out there.

   - Phil

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
Interface layer.

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).
    
;rob

  Robert C. Pettengill, MCC Software Technology Program
  P. O. Box 200195, Austin, Texas  78720
  ARPA:  rcp@mcc.com            PHONE:  (512) 338-3533
  UUCP:  {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp