3 ms·

Threads don’t hold references - other objects do and we have to know how many do. If threads held a reference it might never be released. Since most objects are

Threads don’t hold references - other objects do and we have to know how many do. If threads held a reference it might never be released. Since most objects are never shared we wouldn’t want to increment an atomic counter even once for those.

a1369209993 5y ago
I don't think the objection you're actually making is valid (the extra atomic reference is just a representation of the fact that the local refcount is nonzero), but come to think of it, even in the original version, how the heck does a thread know whether a reference held by (say) a dictionary that is itself accesible to multiple threads was increfed by the owning thread or another thread?
kccqzy 5y ago
I think you have misunderstood GP. GP is trying to say, the thread that created the object has a remote (atomic) reference count of 1, in addition to a local reference count of 1. the remote reference count is simply initialized to be 1. During this initialization operation no atomic operation is used. The only atomic operation is during destruction: the local reference count is decremented non-atomically, and then if it is zero, we need an atomic memory_order_release decrement for the remote reference count.
- a1369209993 5y ago
  > and then if it is zero, we need an atomic memory_order_release decrement for the remote reference count. Actually, we don't. We need a atomic load, but if the results of that load indicate that we're destroying the last reference to the object (which does need to be more complicated than just a extra remote reference; see [0] and [1]), we can just destroy the object as-is without actually doing a atomic store, because by definition there is no reference to the object through which another thread could inspect the remote refcount. (If there was, our reference wouldn't be the last one.) 0: https://news.ycombinator.com/item?id=28883218 https://news.ycombinator.com/item?id=28883218 1: https://sci-hub.se/https://dl.acm.org/doi/10.1145/3243176.3243195 https://sci-hub.se/https://dl.acm.org/doi/10.1145/3243176.32...

a1369209993 5y ago

I don't think the objection you're actually making is valid (the extra atomic reference is just a representation of the fact that the local refcount is nonzero), but come to think of it, even in the original version, how the heck does a thread know whether a reference held by (say) a dictionary that is itself accesible to multiple threads was increfed by the owning thread or another thread?

kccqzy 5y ago

I think you have misunderstood GP. GP is trying to say, the thread that created the object has a remote (atomic) reference count of 1, in addition to a local reference count of 1. the remote reference count is simply initialized to be 1. During this initialization operation no atomic operation is used. The only atomic operation is during destruction: the local reference count is decremented non-atomically, and then if it is zero, we need an atomic memory_order_release decrement for the remote reference count.

a1369209993 5y ago
> and then if it is zero, we need an atomic memory_order_release decrement for the remote reference count. Actually, we don't. We need a atomic load, but if the results of that load indicate that we're destroying the last reference to the object (which does need to be more complicated than just a extra remote reference; see [0] and [1]), we can just destroy the object as-is without actually doing a atomic store, because by definition there is no reference to the object through which another thread could inspect the remote refcount. (If there was, our reference wouldn't be the last one.) 0: https://news.ycombinator.com/item?id=28883218 https://news.ycombinator.com/item?id=28883218 1: https://sci-hub.se/https://dl.acm.org/doi/10.1145/3243176.3243195 https://sci-hub.se/https://dl.acm.org/doi/10.1145/3243176.32...