[Ecls-list] Thread safety audit

[Tobias C. Rittweiler]

Hi Matthew,

regarding the audit, you should ask the Clisp people who have been doing
an audit, too, over the last few months. You could ask them where they
found Clisp was thread-unsafe. 

Packages & interning reader, random-state and calls to RANDOM,
hash-tables used in CLOS implementation, COMPILE and COMPILE-FILE, OS
filesystem primitives come to mind immediately.


Matthew Mondor <mm_lists at pulsar-zone.net>
writes:

> Hello again,
>
> Lately I noticed a message about problems with ECL and thread-safety in
> the slime logs.  I've personally used ECL with multithreading for some
> tests and those seemed successful, however I admit I've not used CLOS
> in those, and shared objects such as hash tables (not only accessed
> read-only) were explicitely protected using a mutex.

You can put (setf swank:*communication-style* :spawn) into your
~/.swank.lisp so Slime will use threads on ECL. If you also have
(slime-setup '(slime-fancy slime-asdf)) into your .emacs, cursor motion
will involve background threads responsible for displaying the arglist
in the minibuffer.

I think, you'll see segfaults of ECL every now and then.

The bit about CLOS was just an unsubstantial guess because the automatic
arglist display does involve a little bit of CLOS.

Also because compilation go through gcc, compilation is quite slow. So
if you press C-c C-c twice in a row, you have two concurrent threads
trying to compile something which will usually result in a segfault,
too.


> I've been wondering though: did the slime code also use explicit locks
> around any objects where a possible race condition was possible?  Or
> did it expect some automatic synchronized access to some objects?  If
> the later, do other implementations of Common Lisp automatically
> synchronize access to a subset of object types?

It does explicitly lock on its own implementation. But it does not try
to prevent stuff like concurrent compilation/evaluation, etc. or
anything listed above.


> Tonight when I got home I decided to take a look at how multiple values
> returned from functions worked, to make sure that those weren't a
> problem, but inspecting the generated C code showed that those are
> filled into a thread-specific array, so it shouldn't be an issue.  I
> also used multiple return values successfuly with threads.
>
> Will remain to also inspect the tread (un)safety of structure and CLOS
> objects, as well as hash tables, which I plan to continue doing as time
> permits, but I also wanted to know what auto-synchronization
> expectations CL users might have.

You cannot have any. I personally do not think that cross-implementation
multi-threading is viable in Common Lisp.

On SBCL, I usually write code with the assumption that unspecialized,
and specialized-to-immediate, slot writes (of structures and classes)
involve the write of one memory location and are hence atomic on x86 in
so far that concurrent reads (e.g. due to print-object methods) won't
read garbage.

  -T.