[Ecls-list] Thread safety audit

[Matthew Mondor]

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.

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?

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.

Thanks,
-- 
Matt