zanmato1984 commented on PR #40647:
URL: https://github.com/apache/arrow/pull/40647#issuecomment-2016868170
> AFAIU, "relaxed" means the statistics could become entirely wrong, e.g.
they could diverge more and more from the actual values. "acq-rel" ensures they
converge to the actual values if no allocation happens for a long enough period
of time.
I think at least in this PR, for most of those monotonically increasing
variables, relaxed atomic makes sense at certain extent:
1. Atomic fetch_add using relaxed MO doesn't lose increment, so the value
will converge, eventually.
2. The "correctness" of these values depends on how they are observed.
Consider a scenario where a main thread creates several concurrent worker
threads and waits for them to finish:
- If the worker threads need to see fresh enough stats numbers (assuming
otherwise the program will behave unexpectedly), then acq-rel is necesary, as
relaxed will cause the worker threads not able to see each other's modification
from time to time (at the worst case, until the thread finished).
- If only the main thread needs to see the stats numbers, then relaxed is
good enough. Because the "happens-before" relationship established by the
thread waiting will guarantee all the modifications made by the work threads
visible to the main thread. As long as the increments don't get lost (and they
won't, as said in 1), the numbers seen by the main thread will be correct.
- Even for the case of "the worker threads need to see fresh enough stats
numbers", though acq-rel will make the modifications immediately visible to
others, the "correctness" is also arguable. Because there is no synchronization
between the underlying allocator and the stats updating, as I mentioned in my
previous comment.
I don't have a strong opinion on either solution, just interested in
exploring all possible feasibilities. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
