write_seqcount_latch_begin(9)

📦 version 7.3.1, in nixpkgs unstable

✨ write_seqcount_latch_begin(9) ✨

okay so this is a page straight out of the Kernel API Manual, and bestie, it's about write_seqcount_latch_begin(9) — the little function that flips your readers over to the odd copy so you can go mess with the even one 🎀

🌸 NAME 🌸

write_seqcount_latch_begin — redirect latch readers to odd copy

Literally what it says. It's giving "traffic cop but for readers" 💅

🦋 SYNOPSIS 🦋

void write_seqcount_latch_begin (seqcount_latch_t *s );

🎀 ARGUMENTS 🎀

  • s — Pointer to seqcount_latch_t. Yep, that's the whole thing. Just hand it the latch and it does its thing 💖

👑 DESCRIPTION 👑

So the latch technique is a multiversion concurrency control method — say that five times fast — and what it does is let queries happen during non-atomic modifications. Slay.

But quick vibe check: if you can guarantee queries never interrupt the modification — like, the concurrency is strictly between CPUs — you most likely do not need this. fr fr, don't over-engineer.

Here's the tea ☕: traditional RCU/lockless data structures rely on atomic modifications to make sure queries see either the old state or the new state. The latch lets you pull off the same thing for non-atomic updates. The trade-off? You're doubling the storage cost 😭 — you have to keep two copies of the entire data structure. Two. Copies. Periodt.

Very simply put: we first modify one copy, then the other. That way there's always one copy chilling in a stable state, ready to give us an answer. Iconic behaviour, honestly.

The basic form is a data structure like:

struct latch_struct {
        seqcount_latch_t        seq;
        struct data_struct      data[2];
};

Where a modification — which is assumed to be externally serialized — does the following:

void latch_modify(struct latch_struct *latch, ...)
{
        write_seqcount_latch_begin(latch->seq);
        modify(latch->data[0], ...);
        write_seqcount_latch(latch->seq);
        modify(latch->data[1], ...);
        write_seqcount_latch_end(latch->seq);
}

And the query has a form like:

struct entry *latch_query(struct latch_struct *latch, ...)
{
        struct entry *entry;
        unsigned seq, idx;

        do {
                seq = read_seqcount_latch(latch->seq);

                idx = seq & 0x01;
                entry = data_query(latch->data[idx], ...);

        // This includes needed smp_rmb
        } while (read_seqcount_latch_retry(latch->seq, seq));

        return entry;
}

So during the modification, queries get redirected to data[1] first. Then we modify data[0]. When that's done, we redirect queries back to data[0] and then we can modify data[1]. See the dance? 🧚 It's a whole choreography and it eats every time.

💀 NOTE 💀

The non-requirement for atomic modifications does _NOT_ — that's a big NOT, underline it, highlight it — include the publishing of new entries in the case where data is a dynamic data structure. Don't come for me.

An iteration might start in data[0] and get suspended long enough to miss an entire modification sequence, and once it resumes it might observe the new entry. 🙈 yeah. awkward.

NOTE2: When data is a dynamic data structure, one should use regular RCU patterns to manage the lifetimes of the objects within. No cap, do this.

⭐ SEE ALSO ⭐

Kernel file ./include/linux/seqlock.h — and the whole extended friend group 🫶:

and that's the whole page, bestie 💖 it lives in ./include/linux, dated October 2026, and yes the footer says write_seqcount_latch_begin(9) again because the kernel loves a callback. go forth and redirect those readers 🦋✨

📦 where this page comes from