Implement concurrent data structures for Issue #2235

[guptapratykshh]

Fixes #2235

Proposed Changes

• implemented concurrent_vector, concurrent_unordered_map, and concurrent_unordered_setusing hpx::shared_mutex for thread safe access(reader-writer lock)
• added concurrent_queue as an alias to hpx::lockfree::queue to provide TBB-compatible interface
• added tbb_hash and tbb_hasher aliases in hash.hpp for compatibility

Any background context you want to provide?

Checklist

Not all points below apply to all pull requests.

• I have added a new feature and have added tests to go along with it.
• I have fixed a bug and have added a regression test.
• I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

Thank you for working on this!

However, I believe the data structures you added are not thread-safe in the sense that they expose non-safe iterators and allow direct access to the stored data elements through unsafe access functions (like operator[]()).

[hkaiser]

Similar comments apply to the other data structures you proposed.

[hkaiser]

@guptapratykshh This pr starts to get in shape. There is still the issue fo the iterator interface exposed by the new concurrent_vector. Also we need to make a decision on whether to (conditionally) support the transparent key functionality introduced in C++26. I'd love to hear your oppinion on the latter.

[guptapratykshh]

thanks for the feedback,on the iterators, you are right. the current std::vector wrapper is definitely a bottleneck. i will redo internal storage using a segmented design to ensure iterators stay stable even when the vector grows

i did also support transparent keys. avoiding temporary allocations on lookups is a clear performance win that fits HPX perfectly

[hkaiser]

thanks for the feedback,on the iterators, you are right. the current std::vector wrapper is definitely a bottleneck. i will redo internal storage using a segmented design to ensure iterators stay stable even when the vector grows

I don't think we need iterators to be exposed from the concurrent_vector. You don't have them exposed from the associative data structures either.

i did also support transparent keys. avoiding temporary allocations on lookups is a clear performance win that fits HPX perfectly

If you want to add those, you will need to add a feature test that ensures transparent keys are supported by the underlying standard containers.

[hkaiser]

inspect is unhappy still as well:

/libs/core/concurrency/include/hpx/concurrency/concurrent_unordered_map.hpp: *I* missing #include (cstddef) for symbol std::size_t on line 38
/libs/core/concurrency/include/hpx/concurrency/concurrent_unordered_set.hpp: *I* missing #include (cstddef) for symbol std::size_t on line 36
/libs/core/concurrency/include/hpx/concurrency/concurrent_vector.hpp: *I* missing #include (cstddef) for symbol std::size_t on line 35, *I* missing #include (hpx/modules/errors.hpp) for symbol HPX_THROW_EXCEPTION on line 62
/libs/core/concurrency/tests/performance/concurrent_structure_performance.cpp: *I* missing #include (utility) for symbol std::pair on line 58, *Lic*

[hkaiser]

There are still open comments, please have a look. Also, please rebase this onto current master to resolve potential compilation problems.

[guptapratykshh]

@hkaiser i think this is ready to be shipped, if any reviews will look into that

[hkaiser]

LGTM, thanks!

[hkaiser]

@guptapratykshh Thank you for your patience with this! Good job!