On 30 April 2010 12:27, Giovanni Gigante <giov@...> wrote:
> What I found surprising is that there is no REMHASH anywhere in my code;
That is indeed surprising.
> the threads just write to that hash table, and the values are always
> numbers, so once an entry contains a number, that number might change
> but never disappear. Or so I thought.
Yes, that should be the case. (SETF GETHASH) overwrites the last
entry, and :SYNCHRONIZED T should be enough to guarantee that other
readers don't see the table in an inconsistent state.
About the only thing I can think of that could be causing trouble is
violating CLHS 3.6:
For hash table traversal operations, new elements may not be added
or deleted except that the element corresponding to the current hash
key may be changed or removed."
The important thing is that this applies to all threads. See MAPHASH docstring:
"Consequences are undefined if HASH-TABLE is mutated during the call to
MAPHASH, except for changing or removing elements corresponding to the
current key. The applies to all threads, not just the current one --
even for synchronized hash-tables. If the table may be mutated by
another thread during iteration, use eg. SB-EXT:WITH-LOCKED-HASH-TABLE
to protect the MAPHASH call."
So if you have a thread using MAPHASH or WITH-HASH-TABLE-ITERATOR and
another thread writing to the same table in parallel, that could be
the source of your troubles. In that case, add WITH-LOCKED-HASH-TABLE
around the MAPHASH/W-H-T-I.
If hash table iteration is not involved, I'm stumped right now.