Hello!
I am currently working with your multi-threaded ALEX implementation (ALEX+/alexol). Thank you for this contribution 馃檪
While reviewing the code, I noticed a potential concurrency issue in the find_payload function:
https://github.com/gre4index/GRE/blob/master/src/competitor/alexol/src/alex_nodes.h#L1586
In this function, the metric num_lookups_ is incremented without exclusive/write permissions. As far as I understand, find_payload uses an optimistic lock, meaning multiple threads may execute this code path concurrently without acquiring the leaf node鈥檚 lock.
However, the metric is updated via a plain num_lookups_++, which is not atomic and may lead to lost updates or incoherent values under concurrent execution.
Is my understanding correct?
If so, I would suggest replacing this line with something like:
ADD(&num_lookups_, 1);
(or any other atomic increment mechanism already used elsewhere in the codebase).
Many thanks for your time and for considering this suggestion.
Best regards,
Noelia
Hello!
I am currently working with your multi-threaded ALEX implementation (ALEX+/alexol). Thank you for this contribution 馃檪
While reviewing the code, I noticed a potential concurrency issue in the find_payload function:
https://github.com/gre4index/GRE/blob/master/src/competitor/alexol/src/alex_nodes.h#L1586
In this function, the metric num_lookups_ is incremented without exclusive/write permissions. As far as I understand, find_payload uses an optimistic lock, meaning multiple threads may execute this code path concurrently without acquiring the leaf node鈥檚 lock.
However, the metric is updated via a plain num_lookups_++, which is not atomic and may lead to lost updates or incoherent values under concurrent execution.
Is my understanding correct?
If so, I would suggest replacing this line with something like:
ADD(&num_lookups_, 1);
(or any other atomic increment mechanism already used elsewhere in the codebase).
Many thanks for your time and for considering this suggestion.
Best regards,
Noelia