is_unique for ArcArray

[daniellga]

Implement this function to know if the inner Arc is shared.

[bluss]

Is it possible to make this a non-mut method?

[daniellga]

Wouldn't it risk creating a race condition? I kinda got confused on this point... The alternative would be just to sum strong and weak counts:

fn is_unique(&self) -> bool {
    Arc::strong_count(&self.data.0) + Arc::weak_count(&self.data.0) == 1
}

[bluss]

I was thinking there are race conditions anyway, because the method only returns a boolean. There's no solving that without creating something entirely different. But there's the &mut itself that maintains some exclusivity, that's true.

What's the use case for this?

[daniellga]

In my case I am using an ArcArray as the core of a struct that I call from other language. I want the user of that language to be able to know when a certain method, lets say for example fft calculation, has created a copy of that inner ArcArray.

[bluss]

It is confusing, and if there would be weak refs you're right that it's racy. ArcArray doesn't support weak refs at all. That means there are two options - (1) the way of just checking strong count and deciding we can never support Weak refs or (2) your get_mut implementation which is more sure to always be safe.

Any "is_unique -> bool" method is racy unless we can control the current Arc, i.e we are sure nobody's cloning the exact Arc handle we are holding. For this reason, ownership or &mut of the current Arc is needed to be sure of that.

I would say both (1) in combination with holding or having the option to hold a &mut Arc would be just as safe as (2) for ArcArray, but which choice to use doesn't matter so much to me.

If there is code that first .clone()s and then mutate (unsharing) your ArcArray, you won't notice this way, because the final effect is two independent copies of the data.

[daniellga]

You are saying something like this for (1)?

fn is_unique(&mut self) -> bool {
    Arc::strong_count(&self.0) == 1
}

I am ok with both choices, I just used the second one because of extensibility, in case you choose to use weak references in the future, for whatever reason. Let me know if you have any better suggestion than this.

[bluss]

I think it's clear it's possible to make it a non-mut method - using strong_count.
That seems to be compatible with the use case as well (your use case - if you want to ensure the Arc is not concurrently cloned, you can hold a &mut to the ArcArray, the method doesn't need to use &mut for that). I can't imagine too many other use cases, other than some user wanting to do something they shouldn't w.r.t mutability and sharing 😆.

Any other ideas about use cases?
Maybe get_mut is the safest choice for unknown use cases?

[daniellga]

I will modify it then to count strong count and accept self. Another approach would be to allow access (a getter) to the inner arc, then the user could do whatever he wanted with it.
Just for curiosity, why do you want to make it non-mut?

[bluss]

For non-mut, just the instinct that it's an interrogating method that doesn't modify.
Inner fields won't be exposed 🙂

[bluss]

Can now be rebased on master because clippy errors are fixed there.

[bluss]

Thanks