Is ConcurrentHashMap read lock-free?

[丁一]

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?

[Gaurav Mogre]

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!