The CommonLispHyperSpec does not standardize thread support for CommonLisp. This is unfortunate, but not uncommon for language standards of around that time.

* What CommonLisp implementations support threads?
* What kind of threads? See GreenVsNativeThreads.
* On what platforms?
* What cross-platform APIs exist for managing threads?

Possible sources of information:

* http://common-lisp.net/~dlw/LispSurvey.html

----

Franz's AllegroCommonLisp has thread support. On Windows, they use OS threads, but only one thread can execute Lisp at a time -- foreign calls are non-blocking. Thread support on other platforms apparently uses "green" threads -- the threading is emulated within the Lisp process, a strategy that is also often implemented in other languages.

See: http://www.franz.com/support/tech_corner/newmp-090504.lhtml


CormanCommonLisp supports OS threads on Windows.

CLisp does not to support threads.

----
Lisp threading status (googled 2005-02-21, updated partially 2007-02-17)
* OpenMcl
** http://openmcl.clozure.com/Doc/ch04.html
** Native OS threads from 0.14 onwards. SMP
* SBCL
** Native OS threads on Linux, FreeBSD, and x86/Darwin. SMP
*** Note: Threads are extremely expensive in SBCL. Whereas in a Java program you may be able to get thousands of threads to run, the following may or may not cause the error message "Can't create a new thread" on your system:
**** (loop repeat 590 do (make-thread (lambda () (sleep 5))))
* CMUCL
** Green threads
* LispWorks
** Native threads on Win32, OS X, Linux. (Non-SMP)
* Allegro CL
** Native and green threads on most platforms. (Non-SMP)
* Corman CL
** Native threads on Win32
* Clisp
** No native threads as yet (as of 2005-02-21)

----

Would someone mind explaining why it is such a problem to add threads to Lisp, if it is not too complicated for a non-Lisp user?  I have read through WhyWeHateLisp which seems to focus on the lack of thread support as one of the main reasons it is not more widely used.

''It isn't that Lisp doesn't have threads.  It is that thread support in Lisp isn't part of the standard... every Lisp implementation is off doing its own thing, and sometimes that thing can also vary on a per-platform basis, harming both portability between implementations and between operating systems.  Lisp could do better, but C/C++ and many other languages suffer from the same problem.''

Lisp seems really interesting and seems to have a lot of support from seasoned developers, but it would be nice to have some comfort that I could eventually develop business applications without worrying about issues such as threading.

''That's easy.  For the most part, regular business applications don't need threading... which is fortunate because the moment you introduce threading you shouldn't ''not'' worry about threading issues.  Even languages that standardize thread support often could do much better in reducing "issues such as threading". I'd personally like to see SoftwareTransactionalMemory and a composable '''atomic''' block keyword instead of primitive mutexes and monitors (with their potential for deadlock, livelock, their lack of composability tending to violate modularity, etc.).  I also wouldn't mind a more message-passing concurrency model (even if messages are 'passed' efficiently in shared memory).''

----
CategoryLisp