You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
when I read the ConcurrentHashMap implementation, the ConcurrentHashMap's operator[] will finally call
"ensureSegment(segment)->insert(res.first.it, h, std::move(foo));_", which uses BucketTable'sdoInsert function. And at the function begining, has a unique_lock. So I think ConcurrentHashMap's read is not lock-free. Do I get mistake on this question?
The text was updated successfully, but these errors were encountered:
NoWarnNoError
changed the title
Is ConcurrentHashMap
Is ConcurrentHashMap read lock-free?
Nov 28, 2023
Technically ConcurrentHashMap reads are indeed lock-free (and wait-free). An operation like find() will does not need to lock a bucket.
However the operator[] is not a read-only operation. Similar to a regular std::unordered_map, doing a auto& value = map[5]; when 5 doesn't exist would result in creating an entry for key = 5 with default constructing it's value, and then returning a reference to that value. This is a write-oriented operation, and hence is NOT lock-free.
An alternative would be to use map.at(5) which is indeed lock-free. Most (all?) const member functions of ConcurrentHashMap are lock-free
Technically ConcurrentHashMap reads are indeed lock-free (and wait-free). An operation like find() will does not need to lock a bucket.
However the operator[] is not a read-only operation. Similar to a regular std::unordered_map, doing a auto& value = map[5]; when 5 doesn't exist would result in creating an entry for key = 5 with default constructing it's value, and then returning a reference to that value. This is a write-oriented operation, and hence is NOT lock-free.
An alternative would be to use map.at(5) which is indeed lock-free. Most (all?) const member functions of ConcurrentHashMap are lock-free
Thanks your reply, I also read the code find the answer. Issuing this question verifies my thought. Thanks!
when I read the ConcurrentHashMap implementation, the ConcurrentHashMap's operator[] will finally call
"ensureSegment(segment)->insert(res.first.it, h, std::move(foo));_", which uses BucketTable's doInsert function. And at the function begining, has a unique_lock. So I think ConcurrentHashMap's read is not lock-free. Do I get mistake on this question?
The text was updated successfully, but these errors were encountered: