Add racerelaxed::OnceNonZeroUsizeRelaxed.

[briansmith]

Add a variant of OnceNonZeroUsize that uses relaxed ordering, for reduced overhead, especially on ARM/AArch64 and other weakly-ordered systems.

Examples:

 	adrp	x8, :got:_ZN4ring3cpu3arm12featureflags8FEATURES17habb4a2487137fb15E
 	mov	x19, x0
	ldr	x8, [x8, :got_lo12:_ZN4ring3cpu3arm12featureflags8FEATURES17habb4a2487137fb15E]
-	ldar	x8, [x8]
+	ldr	x8, [x8]
 	cbz	x8, .LBB86_2

 	adrp	x8, :got:_ZN4ring3cpu3arm12featureflags8FEATURES17habb4a2487137fb15E
 	mov	x19, x4
 	mov	x20, x3
 	ldr	x8, [x8, :got_lo12:_ZN4ring3cpu3arm12featureflags8FEATURES17habb4a2487137fb15E]
 	mov	x21, x2
 	mov	x22, x0
 	sub	x23, x3, #4
-	ldar	x8, [x8]
+	ldr	x8, [x8]
 	cbz	x8, .LBB84_8

This is pretty much straight copy-pasta from race to racerelaxed:

git difftool HEAD:src/race.rs src/racerelaxed.rs
git difftool HEAD:tests/it/race.rs tests/it/racerelaxed.rs

[briansmith]

This is pretty much straight copy-pasta from race to racerelaxed:

... after PR #280 and PR #281.

[matklad]

Hm, I am a bit apprehensive here. My overall philosophy is to not include everything possible, and instead leave more niche use-cases to be open-coded by the user.

For a relaxed ordering, I think it might be clearer as well to not use a library for it? At the call-site, with cell.get_or_init(...), you aren't actually seeing that the load is relaxed there! So, open-coding compare-exchange would lead to a more readable code.

So I am inclined to say that this is out of scope for once_cell!

[matklad]

But perhaps it's worth publishing as a separate crate? I don't positively think that this is a bad idea, I am more unsure, and, given once_cell place in the ecosystem, I have to be very conservative with API extensions.

Doing a separate crate removes the uncertainly angle, as you don't pay for what you don't have in Cargo.lock!

[briansmith]

Yeah, I don't disagree with that. Another issue, even with my own usage, is that I probably need OnceNonZeroU8Relaxed and other variants too.