Open xzwj1699 opened 2 years ago
Hello,
Interesting. clht_lb
with no resize does not use the ssmem
, since there is no need to garbage collect buckets (see https://github.com/LPD-EPFL/CLHT/blob/master/src/clht_lb.c).
Some invariants that CLHT has are:
0
-- i.e., value 0
means that the bucket is empty (https://github.com/LPD-EPFL/CLHT/blob/b86ea2c6e6eb178d8d0b0abc38c1ce4386c4ad94/src/clht_lb.c#L163). The application should not use 0 as valid keyschar *
memory and then allocates possibly the same memory and add its back, this can cause correctness issues.Otherwise, I do no see how CLHT could rewrite the pointed by the char *
memory. For CHLT, these are "just" values and w/o resizing, they are never copied or migrated.
hello, I've meet some problem while using clht
at first, I chose the clht_lb_res in my application, and then I got a core dump caused by ht_resize().
then I changed to clht_lb, and init the hashtable like clht_create(5000), and then I got a checksum mismatch(this comes from an asseet in my own application ), so I print all the item in the hashtable(I used it like int --> char*).
and the problem is the char is all right, but the content char point to is changed.
I'am sure that it's clht's problem because after I changed the hashtable to SPTAG(another hashtable implementation), the problem disappeared
so i guess that there may be some hidden bugs in the ssmem part of your program。it maybe implicitly change the contents of the memory, or conflicts with the memory management of my application