where available use AtomicU{64,128} instead of mutex for Instant backsliding protection

[the8472]

This decreases the overhead of backsliding protection on x86 systems with unreliable TSC, e.g. windows. And on aarch64 systems where 128bit atomics are available.

The following benchmarks were taken on x86_64 linux though by overriding actually_monotonic(), the numbers may look different on other platforms

# actually_monotonic() == true
test time::tests::instant_contention_01_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_04_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_08_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_16_threads                   ... bench:          44 ns/iter (+/- 0)

# 1x AtomicU64
test time::tests::instant_contention_01_threads                   ... bench:          65 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:         157 ns/iter (+/- 20)
test time::tests::instant_contention_04_threads                   ... bench:         281 ns/iter (+/- 53)
test time::tests::instant_contention_08_threads                   ... bench:         555 ns/iter (+/- 77)
test time::tests::instant_contention_16_threads                   ... bench:         883 ns/iter (+/- 107)

# mutex
test time::tests::instant_contention_01_threads                   ... bench:          60 ns/iter (+/- 2)
test time::tests::instant_contention_02_threads                   ... bench:         770 ns/iter (+/- 231)
test time::tests::instant_contention_04_threads                   ... bench:       1,347 ns/iter (+/- 45)
test time::tests::instant_contention_08_threads                   ... bench:       2,693 ns/iter (+/- 114)
test time::tests::instant_contention_16_threads                   ... bench:       5,244 ns/iter (+/- 487)

Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.

[rust-highfive]

r? @sfackler

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

Very nice! Thank you for working on this.

[the8472]

since #83776 landed is_x86_feature_detected! is now usable within std.

@rustbot label -S-blocked

[the8472]

It should be ready for review now. I have only tested on x86_64 linux but touched code for other platforms too, so there's a chance that it'll break during a full build.

[jgarvin]

Not sure if this is the right place to ask, but what does this protect against? Why is the tsc less reliable on Windows? I thought rdtsc behavior was only determined by the CPU, not the OS. Is the use of atomics just to facilitate only needing to store a single value regardless of number of threads, or is this somehow trying to make comparing Instants collected on different threads more safe?

[the8472]

I thought rdtsc behavior was only determined by the CPU, not the OS.

Well, it's complicated. The OS plays some role, such as a synchronizing the counters on all cores. Additionally they might inject additional adjustments (e.g. NTP corrections) into some of their time APIs.
But the primary issue is which hardware time source the OS chooses to expose through its time APIs. Linux puts in quite some effort to ensure that TSC is only used when it is reliable and regularly receives updates that mark certain system configurations as unreliable and fall back to different time sources. Historically windows has been less reliable, hence the actually_monotonic() -> bool {false} implementation which results in the Instant being monotonized with a Mutex.

but what does this protect against?

Observed time going backwards when Instants obtained from different cores are compared despite sequential ordering between the Instants, either by happening on the same thread that gets moved between cores or via some synchronization establishing sequential ordering.

Is the use of atomics just to facilitate only needing to store a single value regardless of number of threads or is this somehow trying to make comparing Instants collected on different threads more safe?

The latter. The OS time source is still queried on each Instant::now() call. The obtained value is then checked against the static var and whichever is newer is returned and put back into the static. I.e. it guarantees monotonically increasing values between ordered instants.

There already exists a default implementation of this protection which is based on a Mutex. This PR just offers a faster alternative on platforms that have the appropriate atomics.

[bjorn3]

but what does this protect against?

Observed time going backwards when Instants obtained from different cores are compared despite sequential ordering between the Instants, either by happening on the same thread that gets moved between cores or via some synchronization establishing sequential ordering.

To elaborate on this: The following would panic without backsliding protection if the time moves backwards:

let a = Instant::now();
// some work
let b = Instant::now();
let duration = b - a; // panic: supplied instant is later than self

This panic would need to happen as Duration can only store positive durations.

[ChrisDenton]

But the primary issue is which hardware time source the OS chooses to expose through its time APIs. Linux puts in quite some effort to ensure that TSC is only used when it is reliable and regularly receives updates that mark certain system configurations as unreliable and fall back to different time sources. Historically windows has been less reliable, hence the actually_monotonic() -> bool {false} implementation which results in the Instant being monotonized with a Mutex.

Hm. Is this still an issue with Windows 7+? I'm reading Guidance for acquiring time stamps. The only outstanding issue it mentions is that multiple threads using QPC have ambiguous ordering if the counters only differ by ± 1 "tick".

[the8472]

See #56560 for an example involving windows 10 in a virtualized environment.

[bors]

📌 Commit 17ceb386ee21cfc76ecd00d567df96c06dddc0b8 has been approved by Amanieu

[the8472]

Thanks, fixed. That the sys module and runner share a name but are different platforms is a bit confusing. I should have paid more attention to the module documentation.

[bors]

⌛ Testing commit 17ceb386ee21cfc76ecd00d567df96c06dddc0b8 with merge 87078bd63304a678e0c178410426c1397940a408...

[bors]

💔 Test failed - checks-actions

[Amanieu]

@bors r+

[bors]

📌 Commit cd82b42 has been approved by Amanieu

[bors]

⌛ Testing commit cd82b42 with merge a003591...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing a003591 to master...