Issue #373: A Shared a call hands back stays atomic at yes even where it never crosses a thread

Open and answer this issue on GitHub.

note · opened 2026-10-03 · updated 2026-10-06 · 0 comments

What

At user_parallelism = yes, contracts::sharing lowers a Shared to a plain count where it can prove the value never crosses a thread. ADR-037 D7 says the analysis may only take an atomic away, never add one.

A Shared that came out of a call is never given a plain count today. It is forced to the atomic floor through Fallback::UnseenOrigin (origin_unseen in crates/nikaia/src/contracts/sharing.rs), because the analysis did not see the allocation being made.

That seed was once needed. task::both, the pool the compiler used for automatic statement overlapping, could run a call on a thread of its own and hand its result back. That path is gone:

• the automatic grouping was withdrawn (ADR-292 D1);
• overlap2..overlap8 poll every branch on the block’s own thread (ADR-292 D4).

So the reason a returned Shared crosses has disappeared, while the seed stays. The result is correct (an atomic count is never unsafe, ADR-312 D11), but slower than it needs to be: about 9 ns per clone-and-drop pair (ADR-037 D6).

What it would take

• Follow the allocation across the call: the callee’s ledger would have to say whether the Shared it returns was allocated there and never crossed. This is a new piece of the sharing contract (ADR-312 D11 keeps that contract at the floor, so the column’s meaning would need a decision), or an intra-package analysis that reads the callee’s body.
• Keep the polarity: a missed seed is unsoundness, not a missed optimisation (ADR-037 D7). Every crossing the call itself may perform must still force the floor.
• Prove it pays first: measure on a program that hands Shared values out of functions at yes, before building anything.

Not in scope

user_parallelism = no already makes every count plain (ADR-312 D10).

Back to Open Issues