The Standard Library becomes larger, increasing the maintenance cost.
The maintenance cost may be bigger than it seems, since LLVM does not support such pause function on-the-shelf.
The Standard Library has to maintain architecture-specific implementations of pause.
Alternatives
Do not introduce the std::thread::pause.
No more maintenance cost.
but no support for efficient implementation of spin locks.
If pausing is absolutely necessary, use std::thread::sleep_ms(0) instead, with some performance penalty.
Unresolved questions
How to effectively maintain architecture-specific implementations for the std::thread::pause?
No. yield_now yields to the OS’s scheduler (OS level threading). PAUSE/YIELD yield to the CPU’s scheduler (hyperthreading). yield_now introduces a context switch and the PAUSE/YIELD instructions just hint to the CPU that “now would be a good time to do something else”.
I like the idea, but don’t like the name. Despite being the name of the x86 instruction, the word pause is very generic, and makes me think of either sleeping for a fixed time or until an external signal arrives. Maybe consider a name like yield_cpu, which suggests it is similar to yield_now but also indicates how it is different.
You should clarify whether the function would be defined for all architectures (even if it is an actual nop in some).
Ditto - the posix pause(2) function has quite different semantics (“pause until a signal arrives, perhaps indefinitely”), and it would be terrible to confuse the two (as I initially did when seeing “std::thread::pause”).
This StackOverflow post suggest why it may not be a good idea to have this operation. It suggests that the placement of the instruction is important to its operation, and may be different on different processors. Therefore, the spin-lock should be coded in explicit assembly code, preferably provided by a library.