[Ecls-list] Poll about removal of a feature

Tobias C. Rittweiler tcr at freebits.de
Thu Feb 4 08:29:10 UTC 2010


Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

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

Why are reads locked, but writes not? When does that make sense?

The bit about lock granularity is of course true! However, hash-tables
are not seldomly used just on their own in a global variable used to
note or register things. In that case, just being able to add
:synchronized t, and not having to do anything else is very convenient.

If it's impractical, sure get rid of it. I just wanted to express the
opinion that implementation-provided synchronization can be very
convenient for users.

  -T.





More information about the ecl-devel mailing list