[Ecls-list] Poll about removal of a feature

[Juan Jose Garcia-Ripoll]

On Thu, Feb 4, 2010 at 9:04 AM, Tobias C. Rittweiler <tcr at freebits.de>wrote:

> Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> writes:
>
> > ... if it can be called so.
> >
> > SBCL has opted to make all make all structures unprotected against
> > concurrent access. That means hashtables, arrays, and other structures
> have
> > to be managed by the user taking into account the fact that different
> > threads may try to read / write to them. In other words, those structures
> do
> > not have mutexes, locks, semaphores, etc.
> >
> > I would like to copy that idea in ECL, cleaning up and simplifying the
> > hashtables code.
> >
> > Anybody is against it? Why?
> >
> > Juanjo
>
> SBCL provides :SYNCHRONIZED T for MAKE-HASH-TABLE. For some other
> things, it has big outside locks (e.g. package operations.)
>
> In my experience, it's very nice when you can just add a ":synchronized
> t" to a constructor, and can use the data structure as is -- that is you
> do not need to create a new data structure with new accessors functions,
> etc.pp.


The question is what brings you that "synchronized" and what guarantees it
offers. This flag is _now_ only used at the reading of a hash table, not
during writes, and there the cost is larger than in previous implementations
because it involves creating a lock instead of reusing a global one, as a
user would do. So the current implementation is definitely too lenient for
practical use, I would say.

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/20100204/db6249c3/attachment.html>