This change adds a ForEach method to the AddrHashMap class which can
then be used to iterate over all the key value pairs in the hash map.
I intend to use this in an upcoming change to the memprof runtime.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I couldn't find any unit tests for this hashmap implementation. @vitalybuka if you can point me to an appropriate place, I would be happy to add a test to cover this new method.
some basic unittest could be nice
compiler-rt/lib/sanitizer_common/sanitizer_addrhashmap.h | ||
---|---|---|
112 | ReadLock l(bucket->mtx); |
compiler-rt/lib/sanitizer_common/sanitizer_addrhashmap.h | ||
---|---|---|
125 | I believe all 3 atomic_loads needs memory_order_acquire to make sure that val is loaded after we loaded addr1 | |
128 | cc @dvyukov It would be nice to see patches which use the new function. | |
compiler-rt/lib/sanitizer_common/tests/sanitizer_addrhashmap_test.cpp | ||
2 | first two lines need formating | |
10 | lines 9-12 can be removed | |
35 | maybe delete them from ref as well and then at the end m.ForEach(ExistsInReferenceMap, &reference_map); EXPECT_TRUE(m.empty()); | |
36 | ASSERT_NE() |
Thanks for the review. PTAL!
compiler-rt/lib/sanitizer_common/sanitizer_addrhashmap.h | ||
---|---|---|
128 | I changed the lock type to just a read write lock. The remainder of the code is borrowed from the locked version of acquire (L243-L276) in this revision. If we hold an exclusive lock for the bucket then I don't think we need to ensure that the operations are ordered. Memprof usage is shown in child revision D111676 - see memprof_allocator.cpp L258. It is called when the profiler destructor is called and the contents of the map, i.e. the profile is written out. |
compiler-rt/lib/sanitizer_common/sanitizer_addrhashmap.h | ||
---|---|---|
128 | ReadLock is fine. Thread1: Thread2: So there is data race between Print and Merge |
Thanks for taking the time to clarify with an example, Vitaly. I completely missed the point when you raised it previously. I've reverted the change here and added some documentation to clarify expectations for users. I'll update the child revision with additional locking to prevent the data race on accessing the element.
LGTM, but I slightly prefer you avoid this patch and go with simpler solution on another patch.
ReadLock l(bucket->mtx);