[Ecls-list] Multithreaded code

Juan Jose Garcia Ripoll lisp at arrakis.es
Fri Jan 21 09:02:18 UTC 2005

Valery Syssik wrote:

>Thanks you very match to complete description of integration
>MT run-time's belongs to different languages (Lisp and C for in our case).
>You explain problems:
>1. allocate per-thread resources & separating assess to them.
>2. sharing some resources & serialize access to them.
>I am rather familiar with threading in C/C++ applications,
>and freshman in Lisp threading.
Well, I did not have time yet to write the documentation for the threads 
subsystem, but it is largely inspired by the lisp machine 
multiprocessing package (the manual of which is in some webpage about 
old systems which I can no longer find), and by the implementation 
decisions in other lisps: openmcl 
(http://openmcl.clozure.com/Doc/ch04s07.html), Franz's 
(http://www.franz.com/support/documentation/6.2/doc/multiprocessing.htm) and
SBCL (mostly from reading the source code).

As for the thread issues, there are not that many.

* Hashtables may have a semaphore to allow concurrent access from 
different threads.

* Packages, system properties (i.e. type declarations, proclamations, 
etc) and CLOS generic functions and classes databases are built on top 
of hash tables also allowing concurrent access.

* ECL uses the C runtime that you tell it to. There are no system calls, 
but everything goes through standard ANSI/ISO/POSIX function calls. 
Hence, ECL expects your C libraries to be thread safe, which is the case 
in the Unix world.

* The Boehm-Weiser garbage collector that is shipped with ECL 
understands threads. However, we do not make full use of all the 
possibilities that it offers, such as thread-local allocation.

* In Lisp, to serialize access to a common resource, you use locks. In 
ECL you have most of the functions and macros from the Lisp Machines: 

Unfortunately, as I mentioned above, nothing of this is documented, but 
the code is relatively simple (just two files, src/c/threads.d and 
src/lsp/mp.lsp, plus a number of MUTEX spread around the C core).


More information about the ecl-devel mailing list