* Peter Zijlstra <pet...@infradead.org> wrote:
> +/**
> * raw_write_seqcount_latch - redirect readers to even/odd copy
> * @s: pointer to seqcount_t
> + *
> + * The latch technique is a multiversion concurrency control method that
> allows
> + * queries during non atomic modifications. If you can guarantee queries
> never
> + * interrupt the modification -- e.g. the concurrency is strictly between
> CPUs
> + * -- you most likely do not need this.
Speling nit:
triton:~/tip> git grep -i 'non-atomic' | wc -l
160
triton:~/tip> git grep -i 'non atomic' | wc -l
21
so I guess 'non-atomic' wins?
> + *
> + * Where the traditional RCU/lockless data structures rely on atomic
> + * modifications to ensure queries observe either the old or the new state
> the
> + * latch allows the same for non atomic updates. The trade-off is doubling
> the
> + * cost of storage; we have to maintain two copies of the entire data
> + * structure.
s/non atomic/non-atomic
> + * The query will have a form like:
> + *
> + * struct entry *latch_query(struct latch_struct *latch, ...)
> + * {
> + * struct entry *entry;
> + * unsigned seq, idx;
> + *
> + * do {
> + * seq = latch->seq;
> + * smp_rmb();
> + *
> + * idx = seq & 0x01;
> + * entry = data_query(latch->data[idx], ...);
> + *
> + * smp_rmb();
> + * } while (seq != latch->seq);
Btw., I realize this is just a sample, but couldn't this be written
more optimally as:
do {
seq = READ_ONCE(latch->seq);
smp_read_barrier_depends();
idx = seq & 0x01;
entry = data_query(latch->data[idx], ...);
smp_rmb();
} while (seq != latch->seq);
Note that there's just a single smp_rmb() barrier: the READ_ONCE() is
there to make sure GCC doesn't calculate 'idx' from two separate
reads, but otherwise there's a direct data dependency on latch->seq so
no smp_rmb() is needed, only a data dependency barrier when doing the
first lookup AFAICS?
(This doesn't matter on x86 where smp_rmb() is barrier().)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
