How to dismantle an &Atomic bomb.

[pnkfelix]

Summary

At end of 2020, I tried to get some discussion going about how to write correct code that manages memory based on atomic counters in the memory being managed.

At this point I think the UCG WG has a good proposal: To treat the deallocation capability on the same footing as mutation capability. I.e., if the compiler (or unsafe code author) has a pointer to some memory M where a concurrent actor is allowed mutate M, then one must also allow for the possibility that the concurrent actor may deallocate M (unless of course the compiler/author has some proof or established invariant that the memory M cannot be deallocated).

Background reading

See UCG zulip and T-lang zulip and rust-lang/unsafe-code-guidelines#252

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds
to a possible topic of discussion that may be scheduled for deeper discussion
during one of our design meetings.

[vertexclique]

Is it possible to use a trait boundary to get to the solution proposed by UCGWG? I am thinking something like DeferAlloc for A and DeferDealloc for B where DeferAlloc returns a pointer to the drop implementation of the B and this is only valid if B and A are Sync. These traits can also be designed as parameterized structs like DeferDealloc.

[nikomatsakis]

Scheduled for March 31.

[RalfJung]

Also see specifically this comment for some impact on optimizations / LLVM flags. Summary: the dereferencable flag with its old meaning ("dereferencable for the entire duration of this function call") could only be set for &impl Frozen, but not for references that permit mutation.

For the meeting it might be good to figure out the current status of the dereferencable attribute in LLVM.

[nikomatsakis]

Minutes available here

[RalfJung]

There was also a bunch of interesting follow-up clarification and discussion on Zulip.