On Thu, Mar 11, 2010 at 10:25 AM, Tobias C. Rittweiler <span dir="ltr"><<a href="mailto:tcr@freebits.de">tcr@freebits.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Packages & interning reader, random-state and calls to RANDOM,<br>
hash-tables used in CLOS implementation, COMPILE and COMPILE-FILE, OS<br>
filesystem primitives come to mind immediately<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Also because compilation go through gcc, compilation is quite slow. So<br>
if you press C-c C-c twice in a row, you have two concurrent threads<br>
trying to compile something which will usually result in a segfault,<br>
too.<br></blockquote><div><br>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<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">You cannot have any. I personally do not think that cross-implementation<br>
multi-threading is viable in Common Lisp.<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On SBCL, I usually write code with the assumption that unspecialized,<br>
and specialized-to-immediate, slot writes (of structures and classes)<br>
involve the write of one memory location and are hence atomic on x86 in<br>
so far that concurrent reads (e.g. due to print-object methods) won't<br>
read garbage.<br></blockquote></div><br>Probably close to what I wrote in the previous paragraph.<br><br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br>
<a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>