I heard about some major Lisp companies like Harlequin and Franz to produce MT
versions of CL (at least for Win32) soon. What are the main issues (I mean
troubles here :-)) and non-issues with multithreaded Lisp implementations ? The
more I think about it, the more I fear. If I was to make the Lisp interpreter/VM
multithreaded, should I mutex-protect all the symbols, thus causing major
performance loss ? What about GC - all MT schemes I have read about are an order
of magnitude more complex than single-threaded ones...
Oleg
In article <················@news-win.rinet.ru> ·····@inist.ru (Oleg Moroz) writes:
\\ I heard about some major Lisp companies like Harlequin and Franz to produce MT
\\ versions of CL (at least for Win32) soon. What are the main issues (I mean
\\ troubles here :-)) and non-issues with multithreaded Lisp implementations ? The
\\ more I think about it, the more I fear. If I was to make the Lisp interpreter/VM
\\ multithreaded, should I mutex-protect all the symbols, thus causing major
\\ performance loss ? What about GC - all MT schemes I have read about are an order
\\ of magnitude more complex than single-threaded ones...
\\
\\ Oleg
Lucid and Lispworks, and Allegro I believe, have had multiprocessing on
Unix for a while now. I don't know what their status for win is.
I don't know much about the performance issues, unfortunately. I believe
all the low level synchronization etc (such as setting and binding
variables) you don't have to worry about. Don't take my word for it though.
Sunil
Multithreaded Lisps have been around for years. The problems are
fairly well known and the implementations that Harlequin and Franz
propose will no doubt have all the benefits and problems of the
older mutithreaded lisps.
To answer particular questions, symbols are usually rebound when a
thread takes control, so a mutex is unnecessary. GC is usually
handled at a level lower than the multithreading, but it need not
be. GC is actually a high enough level process that it could run
in parallel with the other processes (with occasional
syncronization). As long as it collects faster than it and other
processes cons, it will finish.
The difficult problems are often race conditions in the mutex code.
If these are very carefully avoided, the rest is not too bad.
The other difficulty is the implicit race in UNWIND-PROTECT.
You can either live with it, or implement something like Lucid
Common Lisp's INTERRUPTIONS-INHIBITED-UNWIND-PROTECT.
·····@inist.ru (Oleg Moroz) wrote:
>I heard about some major Lisp companies like Harlequin and Franz to produce MT
>versions of CL (at least for Win32) soon. What are the main issues (I mean
>troubles here :-)) and non-issues with multithreaded Lisp implementations ? The
>more I think about it, the more I fear. If I was to make the Lisp interpreter/VM
>multithreaded, should I mutex-protect all the symbols, thus causing major
>performance loss ? What about GC - all MT schemes I have read about are an order
>of magnitude more complex than single-threaded ones...
>Oleg
On Tue, 10 Sep 1996 00:40:25 GMT, ·····@capecod.net (Janet Bell) wrote:
>To answer particular questions, symbols are usually rebound when a
>thread takes control, so a mutex is unnecessary.
Sorry, but I don't understand this one. Do you mean that every thread has its
own global and special variables ? How do they cooperate then ? And how should
the implementation manage this rebinding (a thread switch might occur at any
time) ? Keeping the global environment in TLS ?
I really have no experience with multi-threaded Lisp implementations, so I can
only guess here. I'm used (from multi-threaded experience with C, C++ and other
non-functioinal languages) to the POV that threads are light-weight processes
running in the same address space, i.e. sharing the same memory and data
structures, except some kind of thread-local storage.
Oleg