Convert thread storage from std::array to stable_vector with dynamic growth

[anujshuk-amd]

Later will move/remove this
Used by : ROCm/rocm-systems#2542

Motivation

These updates ensure that storage can grow as needed and that concurrent accesses are safely managed.

Technical Details

This pull request refactors the storage management logic in source/timemory/operations/types.hpp to improve thread safety and scalability. The main changes are the switch from a fixed-size array to a dynamically resizing vector for storage, the introduction of atomic and mutex-based synchronization for concurrent access, and the use of a configurable thread limit.

Thread safety and dynamic storage management

• Changed set_storage from using a fixed-size std::array to a dynamically resizing std::vector, allowing for more flexible and scalable storage of thread-local data. ([source/timemory/operations/types.hppL816-R872](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eL816-R872))
• Added atomic and mutex-based synchronization (std::atomic, std::mutex) to ensure safe concurrent resizing and access of the storage vector. ([[1]](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eR42-R45), [[2]](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eL816-R872))
• Implemented an ensure_capacity method in set_storage to grow the storage vector geometrically (doubling size) when a new thread index exceeds current capacity, ensuring efficient scaling and minimizing lock contention. ([source/timemory/operations/types.hppL816-R872](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eL816-R872))
• Updated thread limit configuration by replacing the hardcoded 4096 with the TIMEMORY_MAX_THREADS macro for greater flexibility. ([source/timemory/operations/types.hppL816-R872](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eL816-R872))

Safe access and read logic

• Modified get_storage to use atomic capacity checks before accessing the storage vector, returning nullptr for out-of-bounds thread indices to prevent unsafe reads. ([source/timemory/operations/types.hppR905-R907](https://github.com/ROCm/timemory/pull/21/files#diff-e60a89742e16350cc3b36bbb562d4c77c8b1b7e34bd8a2011b6f81cf13fb771eR905-R907))

Test Plan

To be tested in CI/CD or rocm-system

Test Result

TBA

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[sputhala-amd]

May I suggest you to see if the following approach sounds feasible:

1. Current approach has dynamic_storage_base<StorageType, N> + set_storage<T> : base with get() forwarding to get_storage().
   Instead can we have one type dynamic_storage<StorageType> that owns all behavior. set_storage<T> and get_storage<T> only forward to a single static storage instance for storage<T>*. No base class; the storage type is a single template that encapsulates capacity, growth, and access.

2. Current approach has capacity() takes the mutex and returns m_chunks.size() * ChunkSize. So get_storage()(idx) does if (_idx >= get_capacity()) and pays a lock on every call.
   Instead keep an std::atomic<size_t> m_capacity, updated under the mutex whenever chunks are added. capacity() becomes m_capacity.load(std::memory_order_acquire) with no lock.

3. In current approach every at() / operator[] takes the mutex to read the chunk pointer, so concurrent reads serialize.
   Instead use std::shared_mutex: writers (growth, reserve, ensure_capacity) take std::unique_lock, readers (at(), operator[] when only reading the chunk pointer) take std::shared_lock. Multiple readers can run in parallel.

[sputhala-amd]

dynamic_storage_base::get_storage() returns a static instance, while set_storage<T>::get() below returned a different static _v.

[sputhala-amd]

Should return get_storage(), so there is a single static instance. All set_storage and get_storage logic uses that same instance.

[sputhala-amd]

m_size should be std::atomic<size_t> to ensure thread safety.

[sputhala-amd]

Usage of m_chunks should guarded with locks, because multiple threads could be calling ensure_capacity and add_chunk at the same time.

[sputhala-amd]

After ensure_capacity(idx), at()/operator[] did (*m_chunks[idx/ChunkSize])[idx%ChunkSize] while another thread could be calling add_chunk() and modifying m_chunks.

[sputhala-amd]

reserve here is also not thread safe, should be guarded with lock.

[sputhala-amd]

The PR commit history is difficult to follow because it includes unrelated changes.
Could you please create a fresh branch from rocprofiler-systems and open a new PR containing only the intended changes? This will make the review much easier.