[Openmcl-devel] Hash Table anomaly -- hash-table-size decreases - wondering how this can happen

[Madhu]

*  Glenn Iba <giba at alum.mit.edu>
Wrote on Mon, 5 Jan 2015 17:10:59 -0500

|   I was confused by your previous messages.  You talked about
|patching and re-building -- all way over my head :( Then you said to
|ignore it since the kludge didn't work (or something like that).

I understand, that was my fault.. :)

|This seems to fix the problem of the hash-table shrinking.  And Gail
|Zacharias posted that there was a bug in CLRHASH for :lock-free
|hash-tables that she'd work to fix.  The ticket she referenced talks
|about how the bug only occurs in :lock-free hash-tables.
|
|I'm happy to use the :lock-free NIL hash-tables for now, but I'm
|wondering what the differences are, if any, in how my hash-tables
|should behave with :lock-free nil.  The :lock-free business is
|apparently CCL specific, so a pointer to documentation would be
|helpful [or even better, a description of how to FIND it in the
|documentation so I can look for other things without bothering people
|:)

The only documentation I saw was in the ccl source code:
ccl/level-0/l0-hash.lisp:

(defparameter *lock-free-hash-table-default* :shared
  "If NIL, hash tables default to using the standard algorithms, with locks for shared tables.
   If :SHARED, shared hash tables default to using the \"lock-free\" algorithm,
   which is faster for typical access but slower for rehashing or growing the table.
   Otherwise, all hash tables default to the lock-free algorithm")

[this variable is used as the default value for the :lock-free keyword
parameter in make-hash-table.  I believe The "lock-free" algorithms
are a class of algorithms which avoided multiprocessing thread-level
locks, in the presence of multiple SMP threads, and this has been a
fad in the last decade or so...]

As I said, I'm not a primary ccl user or on the list, but I happened
to be on a machine with ccl-1.10 source, and thought I spotted a quick
kludge, but it turned out to be more complicated and I didn't
understand the assumptions in the code.  I expect Gail will fix this,
and only commended the ":LOCK-FREE NIL" as an interim suggestion. ---Madhu