[Openmcl-devel] Address-based hashing considered harmful. Maybe.

[Gary Byers]

On Mon, 3 Mar 2003, Tim Moore wrote:

> You might consider another axis of optimization: thread-safe vs. not.  It
> wouldn't surprise me to find that many uses of hash tables are
> synchronized at a higher level than the hash table accesses themselves,
> e.g. the hash table is only referenced from the stack of one thread, or
> the application has locked whatever object the hash table is part of.

That's certainly true of some of the hash tables that're used in the
implementation (and that also uses conses/arbitrary objects as keys).

> But
> I suppose it's true that you always need to synchronize with GC with the
> address-based scheme?

Yes; it doesn't have to be as heavyweight as it was in the alpha release
of a few days ago, but there needs to be some coordination.

> Can GC happen between any two instructions in
> OpenMCL now?

Yes.  In 0.13, it was possible to avoid GC by disabling the (lisp-based)
scheduler and being careful not to cons.  In 0.14, you can (and sometimes
have to) temporarily disable the GC.

>
> It would be too bad to make eq hashing of conses perform worse than
> hashing other structures, if only because it violates user expectations.
>

I think that I've sobered up and pretty much talked myself/been talked
out of having hashing by address perform any worse than it does now; I
think that there is probably also room for a strong assertion that a
hash table does not/will not use address-based keys (and also room
for the thread-local assertion.)

> Tim

There are (incidentally) newer alpha binaries in the testing directory;
locking of hash-tables and packages and GC-inhibition should all be somewhat
faster.  (The changes are in CVS, but were a little hard to bootstrap from
last week's binaries.)



_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel