Intrusive reference counting

Shared ownership where the refcount lives in the object rather than beside it. The follow-up — what exactly is thread-safe here — is what the exercise is actually for.

Learn

Atomic reference counts, the memory ordering an increment needs versus a decrement, intrusive vs external counts and what each costs, reference cycles and why a weak handle needs a different mechanism.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "Intrusive reference counting"
What I'm building: A RefCounted<T> base plus a Handle<T> that manages it. Then add a way to observe without owning, and be honest in your notes about what that costs you compared with an external control block.
Concepts I need to own: Atomic reference counts, the memory ordering an increment needs versus a decrement, intrusive vs external counts and what each costs, reference cycles and why a weak handle needs a different mechanism.

Run this as implementation coaching, not a lecture. One design decision at
a time. Wait for my code before moving on.

Per decision:
1. Frame it. State the decision in one line, then the options and what each
one costs. Assume I write C++ but have never had this explained properly.
No jargon without defining it.
2. "The 60-second version" — how a strong candidate would DEFEND that choice
out loud. First person, spoken register, no bullets, no headers. That's
what I'm rehearsing.
3. Tell me what to write, and ask me one question about the edge case I'm
most likely to get wrong.

When I show you code, reply in exactly this shape:

Verdict: correct / partly correct / wrong — one line on what's wrong.
What breaks: the input or sequence that breaks it. Only if something does.
Vocabulary: only if I used a wrong or vague term. Give the right one.
Example answer: how I'd defend this design out loud, 30 seconds, first person.
More info: define any term I probably don't know, one line each.
Follow-up probe: the one question an interviewer asks someone whose code
looks like that.

Skip any section that doesn't apply. Don't pad. If it's wrong, say wrong —
don't soften it.

Do not write my implementation for me. If I ask, refuse and ask what I'd
try instead — I need to defend this code with the editor closed.

Do

A RefCounted<T> base plus a Handle<T> that manages it. Then add a way to observe without owning, and be honest in your notes about what that costs you compared with an external control block.

Check

You're done when all of these are true:

You can say which memory ordering each refcount operation needs, and why the decrement is the interesting one
You can state precisely what is and isn't thread-safe — the count is, the object is not
You can explain what intrusive counting buys you (one allocation, better locality) and what it costs (the type must opt in, no weak observation for free)
A cycle is demonstrated leaking in a test, deliberately

Ship

Repo, plus a short write-up comparing intrusive against an external control block.

Practice with AI

Use these to make the AI your examiner, not your author. If the AI wrote the code, this node doesn't count — you can't defend a design you didn't make.

P2 — adversarial test suite (try to break my implementation)
P3 — HFT-style code review, ends in hire/no-hire
P6 — defend your design decisions with the code closed

Resources

cppreference — std::atomic