[Openmcl-devel] Thread-safe hash table

[Gary Byers]

[I sent a reply to your first question; I moved recently and am still 
unpacking and reconfiguring
hardware, and I'm not sure if that reply is lost or if it's still 
floating around in the ether.  Or
ethernet ...]

Unless otherwise stated, it's safest to assume that most operations in 
CL in general and CCL
specifically don't offer arbitrary guarantees of atomicity.  Things like 
INCF are defined in terms
that preserve evaluation order in the presence of side-effects and 
introduce temporaries for
those reasons; a compiler -might- (and hopefully often does) recognize that

   (incf (aref x 17) 1)

could compile to an instruction that adds 1 to the memory location that 
contains the 17th
element of the array X, but it's likely another matter to ensure that if 
two threads try to
execute that INCF "at the same time" that memory location contain a 
value that's 2 greater
than the value it contained before those INCFs.  Ensuring that those 
INCFs happen atomically
may be many times more expensive than not doing so; on x86, some kinds 
of memory
synchronization operations can negatively affect performance of all 
cores/threads in a system.

(SETF GETHASH) has to internally has to internally do something like 
GETHASH in order to
determine whether it's replacing the value in an existing key/value pair 
or adding a new pair
to the table.   In that particular case, the GETHASH-like operation and 
the SETF have to
happen atomically, and this is usually enforced by using locks or by 
using those expensive memory
operations.

Arbitrary CL operations (AREF ...) don't generally have those kinds of 
constraints; if you need
to enforce them for application-specific reasons, you need to either:

   1) use locks
   2) use undocumented CCL primitives that aren't really ready for 
prime-time.

Those undocumented primitives are undocumented for a variety of reasons; 
I think that we have an open ticket suggesting that they be dressed up a 
bit and documented/exported.

I think that there are a few other aspects of this in general that're 
processor-specific, but I also think
that the general rule - unless otherwise stated, assume that concurrent 
modification of data
structures doesn't happen "atomically" in any sense of the word - holds.
On 12/04/2013 01:27 PM, Paul Krueger wrote:
> On Dec 4, 2013, at 1:24 PM, Gail Zacharias <gz at clozure.com> wrote:
>
>> All hash tables in ccl are thread-safe.
>>
> Terrific, thanks. Just to clarify, I presume this means that updates to the hash-table structure itself (i.e. via gethash (setf gethash) and remhash) are thread safe, but that if I need to modify a value within some hash-table entry (say by doing an (incf (gethash …)) that i'll still need to worry about using appropriate locks. Is that correct or is incf also thread-safe (or atomic which would make it thread-safe)?
>
> I tried to find documentation about what is and is not atomic or otherwise thread-safe in CCL, but wasn't successful. Does such documentation exist somewhere that I missed? Or is there some relatively easy thing to look for in the CCL code that might give me a clue about such things?
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>