Anyone have questions about this? Paul and I are responsible for this tech at Google, and we use it extensively for speeding up low-level tricks up to and including userspace RCU without any memory barriers _anywhere_ on the read paths.
You should join one of the threads :) (Also, ping me if you'll be in the Bay Area any time soon.)
P.S. Figuring out you are would have been considerably less annoying if Google+ was actually compatible with Google's multiple-account-at-once single sign on. Oh well.
If the compiler emits instructions that don't trample on registers used in the special section, couldn't the restart handler just be a nop just before the start of the section? No cleanup/prep necessary. I suppose that would severely limit the size of the special section.
In principle, yes, but then you'd need considerable coordination with the compiler. The two things you'd need
- "Don't use these registers in this scope": not out of the range of possibility, but not well supported to our knowledge.
- "Be OK with an unpredictable jump to this label at any time": not going to happen without a LOT of work. This means that the whole crit section can't change the stack pointer, can't stash a register value on the stack, can't...etc. It wouldn't be impossible by any means to write a compiler that does this, but I don't know anyone who has and good luck managing it now.
(Before someone mentions asm goto: a) not supported in Clang, which is a dealbreaker, b) only supports jumps from particular points, not anywhen. The compiler is free to require such a jump to emit cleanup code to match local state to the label being jumped to; we can't do that.)
But we definitely considered trying it that way--it's just not quite practicable, and the workarounds we came up with more expensive than just having the whole crit section be inline assembly. That does work pretty nicely in the latest version (to be posted sooner or later.)
