Re: Writing a Windows Service in Common Lisp



On 2009-02-03, Pascal Costanza <pc@xxxxxxxxx> wrote:
Raffael Cavallaro wrote:
On 2009-02-02 19:55:49 -0500, Zach Beane <xach@xxxxxxxx> said:

Not true. Corman Lisp, Allegro Common Lisp, and LispWorks Common Lisp
all support threads on Windows.

Right, but with LispWorks for example only one thread can be running in
the lisp at a time. Others that are pure foreign calls might run
concurrently but you can't have two *lisp* threads running concurrently
on a multi core machine. So even though LispWorks uses native threads,
those native threads won't use multiple cores if those threads are
running lisp code.


LispWorks 6.0 will not only have removed that limitation, but will
actually introduce support for running threads on different cores.

To do that they will have to rethink their entire idiotic threading API.

Anyone who thinks that a PROCESS-WAIT function is a good idea, needs to go back
to at least the middle 1970's and read a few papers on concurrency.

How can you safely wait for a condition to become true, and be sure that it's
still true after you are done waiting, if you are not holding a lock, that is
atomically given up when you suspend, and re-acquired, and if you have not
re-tested that the condition is still true?

What they need to do is design a sane new multithreading API, and support the
old API as a backwards-compatibility layer on the new threading.

Threads participating using the old API can be routed to the acquisition of a
global mutex which will serialize them. The process-wait function can work
against that mutex: give up the mutex atomically to go to sleep, then
re-acquire the mutex and re-test the condition, possibly going back to sleep if
it's not true.

New-style thread can explicitly grab the mutex before entering any subsystem
based on the old-style threading. Or use some macro like

(mp:with-braindamaged-threading
(legacy-function))

The macro will acquire and release the necessary lock, with unwind protection.
.



Relevant Pages

  • Re: Writing a Windows Service in Common Lisp
    ... the lisp at a time. ... actually introduce support for running threads on different cores. ... to at least the middle 1970's and read a few papers on concurrency. ... global mutex which will serialize them. ...
    (comp.lang.lisp)
  • Acquisition of LispWorks and Liquid Common Lisp
    ... LispWorks, the portable integrated development tool for ANSI Common ... Lisp, is now developed, marketed and supported by LispWorks Ltd. ... LispWorks Ltd will honor Xanalys Lisp maintenance and support ...
    (comp.lang.lisp)
  • Current status of threading in Common Lisp implementations
    ... So it appears that Lispworks and AllegroCL both only support ... simultaneously (though both support 'true' multithreading of foreign ... I run multithreaded Lisp in those implementations. ...
    (comp.lang.lisp)
  • SLIME 1.0-alpha released
    ... We've just released version 1.0-alpha of SLIME. ... We can now happily recommend SLIME to all the Emacs-using Lisp hackers ... except CLISP and ABCL this socket is bound to the loopback interface ... Below is a list of the Lisp implementations that we support and their ...
    (comp.lang.lisp)
  • Re: SBCL just turned 1.0!
    ... you don't always get good support for commercial ... It's a gamble on the quality of the company behind the lisp, ... academics might be interested in them, ... you aren't purchasing insurance, ...
    (comp.lang.lisp)