arc::get_mut/Arc::make_unique are racy

[talchas]

Both of these essentially check that inner().strong == 1 && inner().weak == 1 to check that &mut self is the only reference to the Arc's data. However in between the checks a Weak pointer could be promoted and the Weak pointer dropped, resulting in both checks succeeding. Adding an additional strong check afterwards won't help as the second strong pointer could then be demoted again.

I don't see an obvious way without a two-word atomic read or a generation counter or something of that sort. On 64-bit splitting an atomic64 into two 32-bit sections /might/ be ok, but on 32-bit only allowing 16 bits of refcount seems bad. (There might be something with using a high bit as a lock bit or such?)

[lilyball]

I think you're right.

I'm tempted to say this could be fixed by switching from a strong/weak pair to a num_ptrs/num_weak pair, where every pointer (whether strong or weak) is counted in num_ptrs and then weak pointers are also counted in num_weak. This does lower the number of total pointers (strong + weak) that we can have outstanding, but it's not as restrictive as actually dividing a usize into two halves.

Another alternative might be to use the high bit of the strong pointer as a "there are weak references" marker. I'm not sure how well that would actually work.

And of course we could always just use a spinlock instead.

[sfackler]

Using num_ptrs + num_weak shouldn't actually lower the total number of pointers since each Arc or Weak is larger than 1 byte so you'd exhaust the address space before overflowing num_ptrs.

[lilyball]

Upon reflection I suspect that num_ptrs + num_weak fails for the same reason that get_mut fails, because the destructor of Arc needs to know how many strong references there are, and the only way to get num_strong is with two loads.

[lilyball]

Although it's possible that using num_ptrs + num_strong instead might possibly work.

[talchas]

If that works (which sounds plausible) it has the disadvantage of requiring two atomics on clone() (though they're probably the same cacheline, so it's not as horrible as it might be).

[lilyball]

I still haven't thought it entirely all the way through, but I think that num_ptrs + num_strong will work (as long as num_strong is always modified before num_ptrs). As you say, this will require two atomics on clone().

The other alternative that I think would work is using the low bit of the strong counter as a "has weak" flag that, when set, is never un-set. Once it's set, a spinlock is then used around all relevant accesses to the strong and weak counters. This is more complicated than num_ptrs + num_strong, but has the benefit of meaning that Arcs that don't use Weak won't have to pay any cost (and in fact they'll be slightly cheaper than today, because no atomic load of weak is necessary if the flag is 0).

Incidentally, it appears we do not have a spinlock construct in our stdlib. That's rather unfortunate, as ad-hoc simple spinlocks are not generally ideal. Preferably we'd have a construct that spins some number of times (it looks like pthread on OS X defines that number as 1000) on multi-processor machines before yielding the thread, and yields immediately on single-processor machines.

[bluss]

Split the Arc struct in two: Give Arc another marker type parameter that decides statically if the type should support weak pointers or not. Use default type parameters to make Arc<T> equivalent Arc<T, NoWeak>

Only the NoWeak Arc will permit get_mut and make_unique. Since the Arc source references boost a lot, I tried to find any indication of how this is solved in the boost sphere, and I can't find any solution when weak pointers are involved.

Default type parameters make this seamless for users that don't need weak pointers.

Note: boost shared_ptr has a member function bool unique() but it only considers stong references.

[lilyball]

@bluss That seems like a very heavy-handed approach. The creator of the Arc instance may not know ahead of time whether any code is going to want to create a Weak instance. And at such time as that decision is made, all code that touches the Arc would have to be updated even though that code doesn't really care whether there's a Weak reference.

As for Boost, I glanced at it yesterday and it didn't appear to me that it supported weak pointers.

[bluss]

It is heavy-handed, but it is also flexible, and allows users to only pay for what they use. Didn't we already want to make Weak pointers optional? (What other reason are they unstable for?)

See boost Smart Pointers doc, it has weak_ptr

[lilyball]

@bluss I'm not really sure why they're unstable, the message just says "Weak pointers may not belong in this module".

And you're right, Boost does have weak_ptr, the link I followed before (from the comments of Arc) didn't show it. Looking through Boost's weak_ptr and shared_ptr it appears that shared_ptr::unique() ignores weak pointers entirely and returns true even if there are existing weak pointers (it appears that shared_ptr works the same way our Arc does, with a shared counter (i.e. our strong) and a weak counter (that includes an extra +1 count as long as shared is non-zero).

So the difference here is our Arc's unique-testing needs to care about weak pointers (in order to meet the memory safety guarantees of Rust) but Boost doesn't enforce that.

[lilyball]

I think what we should do today is remove Arc::make_unique and alloc::arc::get_mut. They're both marked as #[unstable] so this is acceptable. Without those two functions, our existing reference-counting implementation works fine. Then we can explore ways to re-add that functionality in the future. It appears that there are zero clients of Arc::make_unique in rust-lang/rust, although checking for get_mut is not so trivial as that name is not unique.

[lilyball]

@alexcrichton You added Arc::make_unique in the first place, and @aturon you updated it to check weak refs. Any thoughts?

[kvark]

@kballard I added arc::get_mut() in order to use it for parallel ECS proof of concept. I don't know if any real projects use it at the moment, so it should be safe to kill, but I'm going to miss it anyways.

[lilyball]

@kvark I would really like to have Arc::get_mut(), I think it's potentially useful, but as long as there's no clients in rust-lang/rust that depend on it right now, I think we should just kill it for 1.0 and investigate ways to safely re-add it in the future.