Rachelint commented on code in PR #6155:
URL: https://github.com/apache/arrow-rs/pull/6155#discussion_r1715237619
##########
arrow-buffer/src/buffer/null.rs:
##########
@@ -131,9 +176,20 @@ impl NullBuffer {
}
/// Returns the null count for this [`NullBuffer`]
- #[inline]
pub fn null_count(&self) -> usize {
- self.null_count
+ match &self.null_count {
+ NullCount::Eager(v) => *v,
+ NullCount::Lazy(v) => {
+ let cached_null_count = v.load(Ordering::Acquire);
+ if cached_null_count != UNINITIALIZED_NULL_COUNT {
+ return cached_null_count as usize;
+ }
+
+ let computed_null_count = self.buffer.len() -
self.buffer.count_set_bits();
+ v.store(computed_null_count as i64, Ordering::Release);
Review Comment:
> > ArrayRef is hold by multiple threads, and they call the null_count
function concurrently, if we use Relaxed, the count_set_bits computation is
possible to be performed many times...
>
> No memory ordering will prevent this, you'd need some mutual exclusion
primitive if this was the goal. However, it doesn't really matter if two
threads race to compute the null count as they'll just set it to the same
value. As we aren't using the write to synchronise other memory operations,
Relaxed would be perfectly valid here.
>
> I do think the proposal to simplify the state is worth considering, as it
will potentially remove a conditional load
Sorry, maybe I didn't state it clearly. Is it possible that, due to compiler
reordering or cpu cache consistence problem, and the actual execution order
becomes:
```
if cached_null_count != UNINITIALIZED_NULL_COUNT {
return cached_null_count as usize;
}
let cached_null_count = v.load(Ordering::Relaxed);
let computed_null_count = self.buffer.len() - self.buffer.count_set_bits();
```
And finally, the computation will be performance one more times? Although it
actually don't affect the correntness.
cc @XiangpengHao
--
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]
