Language-Level Memory Management (C/C++/Rust) Questions

For one producer and one consumer, I would use a fixed-size ring buffer. That is a circular array where the producer writes at tail and the consumer reads at head. It fits the latency goal because there are no dynamic allocations after startup.

Invariants I would preserve:

• head and tail only move forward modulo capacity.
• The producer never overwrites an unread slot.
• The consumer never reads a slot before it is published.
• Each slot holds either an empty state or exactly one live object.

Synchronization choices:

• Make head and tail atomics.
• The producer writes the element first, then publishes the new tail with release semantics.
• The consumer reads tail with acquire semantics before consuming the element.
• Pad head and tail so they do not share a cache line, which avoids false sharing.

Concrete example: with capacity 1024, if head = 17 and tail = 18, slot 17 is valid for the consumer. The producer writes to slot 18, then stores tail = 19. That store is the signal that the data is ready.

Memory-safety issues to watch: object lifetime, destructor calls for non-trivial types, full and empty detection, and not using volatile as a substitute for synchronization. In interviews, I would call this the standard SPSC queue design, and it is usually the best low-latency answer.

I would make ownership explicit in the type and in the name. The cleanest contract is: one function allocates and transfers ownership to the caller, and one matching destroy function releases it. For example, return a struct buffer { void *ptr; size_t len; } through an out-parameter, and document that the caller owns ptr until buffer_free is called.

That removes ambiguity. No other layer should call free directly unless it is the final owner, and after any successful free the pointer should be set to NULL so a second free becomes a no-op or a clear error. If a value needs to move between layers, use a transfer function like buffer_steal, not two independent frees.

Concrete example: a parser hands a 128-byte blob to the cache. The parser no longer touches it, the cache becomes the only owner, and when eviction happens it calls the single release function.

If I cannot change the return type, I would at least rename the API to make the contract obvious, such as make_buffer plus buffer_destroy, and avoid returning raw pointers with unclear lifetime.

A pointer-to-pointer loop makes this clean. The key idea is that cur always points to the link that leads to the current node, so deleting the head uses the same code as deleting any other node.

#include <stdlib.h>

struct Node {
    int value;
    struct Node *next;
};

struct Node *remove_all(struct Node *head, int target) {
    struct Node **cur = &head;

    while (*cur) {
        if ((*cur)->value == target) {
            struct Node *dead = *cur;
            *cur = dead->next;
            free(dead);
        } else {
            cur = &(*cur)->next;
        }
    }

    return head;
}

Concrete example: for 5 -> 2 -> 2 -> 7 with target 2, the function frees both matching nodes and returns 5 -> 7. Time is O(n), space is O(1).

I would not store a raw user_data pointer without a lifetime rule. A callback is just a function called later, and user_data is the context pointer passed back to it. Because the callback may run long after registration, the event loop needs a handle that owns that context or holds a reference to it.

My rules would be:

• Registration returns an opaque handle.
• The handle keeps the context alive while the callback can still run.
• unregister marks the handle cancelled and waits for any in-flight callback to finish before freeing context.
• If callbacks can run on another thread, protect the handle with a mutex or atomic refcount.

Concrete example: if the context is struct request { int fd; char *name; }, the callback can read it safely only while the handle is active. If the caller unregisters, the loop first prevents future dispatch, then waits until the current callback exits, then frees the request.

That is safer than telling callers to free the context whenever they want. In interviews, I would say the API should make dangling pointers impossible by construction, or at least very hard to create.

I would choose the synchronization strategy based on correctness first, then latency. A mutex is still the right answer when several fields must change together and the object has an invariant that must never be observed half-updated. If the critical section is tiny but contention is high, the problem may be the lock, or it may be the layout around the lock.

Decision guide:

• Keep the mutex if updates must be atomic across multiple fields.
• Change the data layout if the lock is not the bottleneck but cache contention is.
• Use atomics if the state is just one or a few independent values, like counters or a version number.

Concrete example: suppose the shared object holds requests, errors, and last_seen_ms. I might make requests and errors atomic counters, but keep a mutex for updating last_seen_ms together with other correlated state. That reduces lock traffic without weakening correctness.

What I would check in practice: contention rate, p95 or p99 latency under load, and whether threads are bouncing the same cache line. If the mutex is simple and the real issue is false sharing, padding or splitting the object can help more than replacing the lock. If the state machine is complex, I would prefer the clear mutex design over a fragile lock-free rewrite.