Re: [clisp-list] Re: Multithreading in CLISP

[<don...@is...>]

Sam Steingold writes:
 > > What will it take to do, and how easy would it be to contribute to
 > > adding multi-threading?
 > 
 > try building CLISP with -DMULTITHREAD and make it work on your platform.

This seems an appropriate place to reopen the discussion last seen on
this list (I believe) on July 22 about why MT is not so trivial.
After that message I reopened a corresponding discussion (from 1996!)
with Franz and got back some stuff that's worth sharing.
There are a number of topics, such as special binding and garbage
collection.  What I thought (and still think) is the major problem is
finding operations that should be regarded as atomic in lisp but
require multiple heap accesses, and arranging somehow to protect
these.  Here's a good example:

Robert F. Rorschach writes: (I hope he doesn't mind me quoting him)
         (aref some-adjustable-array index)
  should either get an error for the index being out of range or return an 
  element of the array.... it shouldn't be possible for the array to
  change size after the internal range test on index but before the
  element is fetched, causing a fetch from outside the actual array.

I assume it's not difficult to insert code to protect such an
operation (on a case by case basis), but I have no idea how to go
about identifying all of them.  And this is what would be needed
in order to make a reliable multithreaded Clisp.

Anyone out there have any ideas about this?  Even some idea of how
many such operations there are?