Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 20, 2018 4:29 pm wrote:

> Linux now (merged into the latest released kernel version, 4.18) actually has
> what could be seen as the reverse of that: "rseq" aka restartable sequences.

Well this is pretty cool. This seems poised to join membarrier(2) and perf_event_open user-space rdpmc via mmap'd page as some of my favorite Linux syscalls/features.

Maybe this lets you build the "holy grain" read-write lock for ready heavy scenarios?

That is, a read-write lock that for an N CPU machine allocates N cache lines, and the readlock() never does any atomic operations (usually).

You'd define your rseq region to load the per-cpu line, check that there are no writers, and the final "commit" operation is an RMW inc of the reader count (on platforms without an RMW it works fine too, so do the normal read + add and the final instruction is the write of the updated total).

Writers need to set the writer-pending byte (atomically is the simplest) and do a membarrier(2) to ensure no readers are in the enter sequence, and then check/wait that there are no readers.

Does it work?

You've moved 100% of the cost to the writers. You could attempt something similar before rseq, with per-thread thread-local reader structs that you'd link to the lock in a lazy way, but it always had a problem somewhere: e.g., if many reader threads access your lock infrequently you accumulate a ton of reader objects linked to the lock, or garbage collection of the records, or you could try to do "best effort" per-cpu but that always needed an atomic operation somewhere to avoid the race with other readers.

Now you can do per-cpu "exactly", so it seems much more feasible.

Of course, really good RW locks aren't as interesting now that RCU, including user-space RCU is more interesting, but it still has its place (it is more of a drop-in replacement for a plain mutex than RCU is, especially when the mutators operate on big complex structures).