Hacker News Reader

Comment by quotemstr | Hacker News Reader

Relying on an implementation detail of the cpuid instruction seems like a very bad idea. It'd be safer, I think, and just as fast, to initially use the atomic version of the code, then NOP out the LOCK prefix once initialization is complete.

View on HN

Intel specifies CPUID to be serialising, this is unlikely to change in the future.

It's actually part of the architectural definition, so Intel could not change this without breaking ISA compatibility. And they take x86 compatibility very seriously!

That can't possibly work. There's just one dispatch_one function but many callsites, and for each callsite you could have multiple distinct predicates.

You'd allocate a trampoline for each predicate, jump unconditionally into that, then jump unconditionally back to mainline code. Each trampoline can be modifier individually. Of course that doesn't work with the current dispatch_once API, though.

Doesn't this have all the same problems as the way they currently do it? The only difference between the two is that Apple's implementation puts the flag in a variable, while you're basically proposing to put the flag in code. You still need to ensure proper ordering on both reads and writes and ensure that speculative execution doesn't end up giving you the wrong answer.

The rules are different when you're an OS vendor who makes all of the hardware that the OS officially supports.

It would be a bad idea for you or I, but for Apple there's no problem. If Intel ever ships a CPU that needs something else, then Apple can update their code for the OS release that goes out on the corresponding Macs.

Requires writing to executable pages, which iOS doesn't have.

iOS doesn't have x86 processors either, does it?

Unless I'm mistaken, the simulator is an x86 implementation of iOS.

Reply on news.ycombinator.com