The 5-year journey to bring restartable sequences to Linux (2019)

efficios.com

34 points·gbrown_··6 comments

I hadn't heard about this. Cool. Two obvious questions:

1) You are supposed to check the cpu number at the start and end of your critical section, to make sure it hasn't changed. But what if it has changed twice? There should be a "changed" flag in the struct, I'd think.

2) Does the single instruction commit not itself need a lock prefix or something similar? Futex has to do something like that unless I'm mistaken.

Actually, 3) if your cpu supports something like TSX (did Intel ever get that working right?), would you want to use that in preference to rseq?

TSX was apparently working right in some chips, but ultimately intel appears to have abandoned it and was sending microcode updates that disable it even for chips where it worked right.

IIUC if the CPU changes even once, your program jumps to (is context switched into) a recovery sequence.

I couldn't follow the reference, and it isn't spelled out in the entry. this sounds like optimistic concurrency control. which is lovely, but performs poorly under high contention. does anyone know offhand (I guess I should track down that paper)

This looks cool!

Predictably it's a C-only API. I'm curious what using this facility would look like from within Golang or Java.

I'll admit I'm not savvy enough to say whether it would really even make sense to try. I'm curious on how it'd interact with the JVM.

It sounds like this could be a behind-the-scenes feature to optimize ThreadLocal class. It doesn't seem like the type of thing you'd use directly.

Reply on news.ycombinator.com