[Ecls-list] Special symbols that might benefit from implicit locking or thread-local bindings

[Juan Jose Garcia-Ripoll]

On Mon, Aug 1, 2011 at 5:32 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> I audited the symbol.d and package.d code today, and wrote down some
> notes about possible future improvements.
>

It would be nice if someone did this for the whole of the Hyperspec :-)


> Although GENSYM is more often used in the compile phase (which is
> single-threaded, at least for now), it can also be used by
> multithreaded user code at runtime.  Because GENSYM is standard,
> it's unlikely that user code would expect to have to use a lock to
> avoid its internal race conditions around *GENSYM-COUNTER*.  So
> possibly that GENSYM should implicitely use a lock, held the whole time
> between the getf and setf.
>

Doesn't the fact that the user may change *gensym-counter* invalidate the
purpose of the lock? The compiler itself sets *gensym-counter* to 0, binding
it locally so there may be no race condition there, since the symbols are
never interned.


> I wondered if a lock was also required for *PACKAGE* access in
> IN-PACKAGE, but I'm unsure, as theoretically every thread has its own
> local *PACKAGE*; but I'm unsure where this binding gets created, I only
> see the ECL_SETQ to set the new package, I might have missed a LET-like
> binding creation operation.  I see a ecl_bds_bind() call for
> *current-process* only in process.d.  There's some bindings related
> code in process_alloc() but I don't think it handles this either.
>

This is indeed more important: what bindings should become local for a
thread by default. Currently the list of variables that become thread-local
is by default empty. Maybe we should at least add *package* to it? Maybe
also create a global binding with the default list of variables so that each
invocation of make-process uses it by default? What do you think?

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/20110801/0980f914/attachment.html>