Describe the current state
With #22 we introduced mutexes in the instruments to prevent data races between the recording of data points in instrumented calls and their collection from MetricReader.
This is needed because most certainly the recording of data points and their collection execute in separate threads.
The necessity for a mutex, in the initial design, comes from the intention of not losing any data points.
Therefore, each data point that needs to be recorded must check if the arraylist is being read and reset for collection.
Describe the desired state
I am not aware of lock-free data structures that allow shared state to be written and read.
A suggestion from @alanmcdade was to use atomics instead of mutexes.
Any suggestions is welcome.
Additional context
Source of this issue zig-o11y/opentelemetry-sdk#22 (comment)
Originally posted in zig-o11y/opentelemetry-sdk#26
Describe the current state
With #22 we introduced mutexes in the instruments to prevent data races between the recording of data points in instrumented calls and their collection from MetricReader.
This is needed because most certainly the recording of data points and their collection execute in separate threads.
The necessity for a mutex, in the initial design, comes from the intention of not losing any data points.
Therefore, each data point that needs to be recorded must check if the arraylist is being read and reset for collection.
Describe the desired state
I am not aware of lock-free data structures that allow shared state to be written and read.
A suggestion from @alanmcdade was to use atomics instead of mutexes.
Any suggestions is welcome.
Additional context
Source of this issue zig-o11y/opentelemetry-sdk#22 (comment)
Originally posted in zig-o11y/opentelemetry-sdk#26