[Ecls-list] Thread safety audit

[Juan Jose Garcia-Ripoll]

On Thu, Mar 11, 2010 at 10:25 AM, Tobias C. Rittweiler <tcr at freebits.de>wrote:

> 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
>

Package operations are protected by a global lock, so they should be thread
safe. That does not mean that there cannot be any collisions -- if two
threads try to create a symbol at the same time, one may succeed and the
other one may not.

COMPILE / COMPILE-FILE are currently reentrant, but there may be problems
when performing concurrent compilation, because they may change
simultaneously several things in the environment: DEFCONSTANT, DEFTYPE,
DEFCLASS, etc, are problematic when two files are compiled concurrently.

DEFTYPE, DEFCLASS and other routines might have problems with thread
concurrency. However the question is how much of "thread safety" you want to
impose. A global lock around all these forms? Only a lock around (SETF
FIND-CLASS)? Method caching is currently thread safe, though.

Stream operations are likely to be unsafe when using certain input formats.
I am currently thinking on operations like reading a character that involves
more than one byte (do we want to impose this operation to be atomic?) or
things like UNREAD-CHAR, that use a per-stream buffer.


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.
>

That is something different and more likely related to reentrancy and thread
safety in the debugger -- what to do when two threads cause an error
simultaneously? This may be the source of all thouse problems


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

I wonder whether it should be possible to impose that data structures
support concurrent access even if the result is not thread safe. I mean,
that two threads are allowed to access a hash table but operations are not
guaranteed to be atomic -- the outcome of a read / write operation is
undefined --. Same should apply to CLOS classes. We can probably guarantee
safety of operations such as changing the class structure, or reading and
writing to slots.


> 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.
>

Probably close to what I wrote in the previous paragraph.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100311/92017715/attachment.html>