Simple Arc implementation (without Weak refs)

[ThePuzzlemaker]

This is a simple implementation of Arc, without weak refs. If there's anything you feel that could be improved (or if I did anything wrong), please tell me. I'm open to recommendations 🙂

[Havvy]

Awesome that somebody is adding such a huge change; I just did a cursory look (this is not my area of knowledge), and I wasn't even going to comment, but one thing caught my eye so hard I had to.

[Havvy]

Saying it's from 1.49 sounds good to me.

Was just for a nit

[Gankra]

Overall this is really great, but it definitely needs some revision.

[Gankra]

and change this to something like:

---

What atomic ordering should we use here? To know that, we need to consider what happens-before relationships we want to ensure (or alternatively, what dataraces we want to prevent). Drop is special because it's the one place where we mutate the Arc's payload (by dropping and freeing it). This is a potential read-write data race with all the other threads that have been happily reading the payload without any synchronization.

So we need to ensure all those non-atomic accesses have a proper happens-before relationship with us dropping and freeing the payload. To establish happens-before relationships with non-atomic accesses, we need (at least) Acquire-Release semantics.

As a reminder, Acquires ensure non-atomic accesses after them on the same thread stay after them (they happen-before everything that comes after them) and Releases ensure non-atomic accesses before them on the same thread stay before them (everything before them happens-before them).

So we have many threads that look like this:

(A) non-atomic accesses to payload
(B) atomic decrement refcount

And a "final" thread that looks like this:

(C) non-atomic accesses to payload
(D) atomic decrement refcount
(E) non-atomic free/drop contents

And we want to ensure every thread agrees that everything happens-before E.

One thing that jumps out clearly is that the non-final threads all end with an atomic access (B), and we want to keep everything else (A) before it. That's exactly what a Release does! So it seems we'd like our atomic decrement to be a Release.

if self.inner().rc.fetch_sub(1, Ordering::Release) != 1 {
  return;
}

However this on its own doesn't work -- our final thread would also use a Release, and that means (E) would be allowed to happen-before (D)! To prevent this we need Release's partner, an Acquire! We could make (D) AcquireRelease (AcqRel), but this would penalize all the other threads performing (B). So instead, we will introduce a separate Acquire that only happens if we're the final thread. And since we've already loaded all the values we need, we can use a fence.

if self.inner().rc.fetch_sub(1, Ordering::Release) != 1 {
  return;
}
atomic::fence(Ordering::Acquire);

If this helps, you can think of this like a sort of implicit RWLock: every Arc is a ReadGuard which allows unlimited read access until they go away and "Release the lock" (trapping all accesses on that thread before that point). The final thread then upgrades itself to a WriteGuard which "Acquires the lock" (creating a new critical section which strictly happens after everything else).

[RalfJung]

However this on its own doesn't work -- our final thread would also use a Release, and that means (E) would be allowed to happen-before (D)!

This sounds like for X, Y we always have that one happens-before the other or vice versa... which is not the way happens-before actually works. Happens-before is a partial order, and some events simply are unordered. So I think it'd be better to phrase this accordingly, saying something like "[...] and that means (D) would not be forced to happen-before (E)". Except that's also wrong, program-order is included in happens-before. The actual issue is between (E) and (A), isn't it? We must make (A) happens-before (E), and that's why there needs to be an "acquire" in the "final" thread.

[RalfJung]

As a reminder, Acquires ensure non-atomic accesses after them on the same thread stay after them (they happen-before everything that comes after them) and Releases ensure non-atomic accesses before them on the same thread stay before them (everything before them happens-before them).

The key thing with an acquire is that the release it reads from (and everything that comes before it) happens-before everything that comes after the acquire. Each acquire is paired with a release, and this pair establishes a happens-before link across threads. Personally, I find this way of thinking about it easier than thinking about the release and the acquire separately. (Also see what I said above: to my knowledge, happens-before includes program-order, so "X happens-before everything that comes after it in the same thread" is true for all X.)

[Gankra]

(probably won't have a chance to review the new changes until monday)

[Gankra]

Looks good!

[Gankra]

thanks a bunch!!