* Fix many benchmarks to be cc_binary instead of cc_test
* Add a few benchmarks for StrFormat
* Add benchmarks for Substitute
* Add benchmarks for Damerau-Levenshtein distance used in flags
PiperOrigin-RevId: 738448552
Change-Id: I521f4b2ef9116c9895b44c32d27e94507380bee8
Applying a non-zero offset to a null pointer is undefined behavior.
Our UBSAN tests were missing `-fno-sanitize-recover`, which
means UBSAN logs a warning, but the program continues,
causing the test not to fail.
`-fno-sanitize-recover` will be added once all errors are fixed.
PiperOrigin-RevId: 733395060
Change-Id: Ibf71d0d2a27fac14f0c33dbdf83f4089645b8b37
The existing implementation uses wall-clock time. However, wall clock can drastically differ from the internal system clock, because the system can be suspended and then resumed.
We want to account for at least some kinds of suspensions that might occur during automated testing, such as VM suspension or hypervisor preemption ("steal time"). These are tricky cases, because the physical (host) CPU is still running -- just the logical (guest) virtual CPU isn't. Therefore, we need to ensure that our time measurements exclude elapsed host-only time.
Unfortunately the correctness of a method depends on the nature & configuration of each VM and the guest. For example, it can depend whether RDTSC is virtualized, or on whether the host and guest support accounting for steal time. Windows, for example, appears to only support steal time measurements if the hypervisor is Hyper-V.
Since this is all for the sake of testing, we use a simpler trick that we hope will work around the problem on our systems: we subtract the so-called "interrupt time bias" from the system uptime in Windows. The interrupt time bias includes sleep/hibernation time, and seems to advance during for VM suspensions as well, so it may take care of the problem.
PiperOrigin-RevId: 675654840
Change-Id: I66150b18912175fa72609d3f137e3ea4fee8fc43
the open source release. This was only used in tests that never ran
as part in the open source release.
PiperOrigin-RevId: 636167506
Change-Id: Iafc33bd768307fe9ee77b181369635012abf2245
and use StdcppWaiter instead.
There are various flavors of MinGW, some of which support pthread,
and some of which support Win32. Instead of figuring out which
platform is being used, just use the generic implementation.
PiperOrigin-RevId: 580565507
Change-Id: Ia85fd7496f1e6ebdeadb95202f0039e844826118
Since ABSL_INTERNAL_HAVE_STDCPP_WAITER is defined on all systems
it is effectively a fallback. I left the condition there in case
we have to disable it on some platform in the future.
PiperOrigin-RevId: 555629066
Change-Id: I76ca78c7f36d1d02dc4950a44c66903a2aaf2a52
Reformat Mutex-related files so that incremental formatting changes
don't distract during review of logical changes.
These files are subtle and any unnecessary diffs make reviews harder.
No changes besides running clang-format.
PiperOrigin-RevId: 541981737
Change-Id: I41cccb7a97158c78d17adaff6fe553c2c9c2b9ed
The non-RAW_ versions provide better output but weren't available when most of these tests were written.
There are just a couple spots where RAW_ is actually needed, e.g. signal handlers and malloc hooks.
Also fix a couple warnings in layout_test.cc newly surfaced because the optimizer understands CHECK_XX differently than INTERNAL_CHECK.
PiperOrigin-RevId: 534584435
Change-Id: I8d36fa809ffdaae5a3813064bd602cb8611c1613
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1433
Some 32-bit configurations may use 64-bit time_t, which leads to different layout of userspace timespec and the one expected by SYS_futex implementation in kernel. In particular the issue occurs when using musl libc which has switched to unconditional 64-bit time_t definition.
This patch introduces custom struct timespec with two longs when old SYS_futex is used to match the kernel timespec definition.
Merge 2eaca415da825b3f31a90f58a35bdef2b6d2a6c5 into f8bf909108
Merging this change closes#1433
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1433 from olegartys:futex_time64_bug 2eaca415da825b3f31a90f58a35bdef2b6d2a6c5
PiperOrigin-RevId: 528796119
Change-Id: Idaa952f64bd97c6dc9703a8b44deac43e29ff9ae
proposed standard pthread_cond_clockwait() and sem_clockwait().
These are currently implemented in glibc >= 2.30.
These methods take a clock and use an absolute time with reference
to that clock, so KernelTimeout now can produce these values.
PiperOrigin-RevId: 522824226
Change-Id: Ife98713f6f95d800b1f8e52d5364a3dbebc4f8a6
This implementation may at some point become the default on some
platforms. Currently not all platforms have widespread support for
both real absolute timeouts or real relative timeouts (here "real"
means without converting to the other timeout type which is the only
one supported by the underlying APIs). In this case we can defer to
their standard library to implement correct support.
This is not currently the default on any platform
Note: The size of WaiterState had to increase to fit the new implementation
PiperOrigin-RevId: 518266646
Change-Id: I7f246646a960d6e1b155f9de0bf2f681c5d3d245
Instead of being only able to test the platform Waiter implementation,
this allows us to be able to test all Waiter implementations that
build on a specific platform.
A unittest is added that tests all implementations that work for the
platform, and allows us to check that the expected one is being used
by printing the name of the selected implementation.
PiperOrigin-RevId: 518072415
Change-Id: Ie9e6fcd9d8283b4038e6f4e68a304d2adcc04b19
Windows tests often run in Emulation, and even with KVM we can still timeout.
PiperOrigin-RevId: 517192968
Change-Id: I3b4e435f8ac8ad1e7eab6f043c051fa75efed64b
monotonic clocks on Linux when the implementation uses futexes
After this change, when synchronization methods that wait are passed
an absl::Duration to limit the wait time, these methods will wait for
that interval, even if the system clock is changed (subject to any
limitations with how CLOCK_MONOTONIC keeps track of time). In other
words, an observer measuring the time with a stop watch will now see
the correct interval, even if the system clock is changed. Previously,
the duration was added to the current time, and methods would wait
until that time was reached on the possibly changed realtime system
clock.
The behavior of the synchronization methods that take an absl::Time is
unchanged. These methods always wait until the absolute point in time
is reached and respect changes to the system clock. In other words, an
observer will always see the timeout occur when a wall clock reaches
that time, even if the clock is manipulated externally.
Note: ABSL_PREDICT_FALSE was removed from the error case in Futex as
timeouts are handled by this case, and timeouts are part of normal
operation.
PiperOrigin-RevId: 516534869
Change-Id: Ib70b83e4be3f9e3f1727646975a21a1d30acb242
timeouts, but when a relative timeout is provided, the timeout is an
absolute timeout against a steady clock (when possible). This allows
methods that return relative timeouts to automatically recompute the
remaining duration, for instance, on suprious wakeups.
PiperOrigin-RevId: 516304139
Change-Id: I7d739cb50dd749eba5dba7ac6c34d18dc53703ed
monotonic clocks on Linux when the implementation uses futexes
After this change, when synchronization methods that wait are passed
an absl::Duration to limit the wait time, these methods will wait for
that interval, even if the system clock is changed (subject to any
limitations with how CLOCK_MONOTONIC keeps track of time). In other
words, an observer measuring the time with a stop watch will now see
the correct interval, even if the system clock is changed. Previously,
the duration was added to the current time, and methods would wait
until that time was reached on the possibly changed realtime system
clock.
The behavior of the synchronization methods that take an absl::Time is
unchanged. These methods always wait until the absolute point in time
is reached and respect changes to the system clock. In other words, an
observer will always see the timeout occur when a wall clock reaches
that time, even if the clock is manipulated externally.
Note: ABSL_PREDICT_FALSE was removed from the error case in Futex as
timeouts are handled by this case, and timeouts are part of normal
operation.
PiperOrigin-RevId: 515043788
Change-Id: I151127b588065bd1316273f36d7c946545c2c892
monotonic clocks on Linux when the implementation uses futexes
After this change, when synchronization methods that wait are passed
an absl::Duration to limit the wait time, these methods will wait for
that interval, even if the system clock is changed (subject to any
limitations with how CLOCK_MONOTONIC keeps track of time). In other
words, an observer measuring the time with a stop watch will now see
the correct interval, even if the system clock is changed. Previously,
the duration was added to the current time, and methods would wait
until that time was reached on the possibly changed realtime system
clock.
The behavior of the synchronization methods that take an absl::Time is
unchanged. These methods always wait until the absolute point in time
is reached and respect changes to the system clock. In other words, an
observer will always see the timeout occur when a wall clock reaches
that time, even if the clock is manipulated externally.
Note: ABSL_PREDICT_FALSE was removed from the error case in Futex as
timeouts are handled by this case, and timeouts are part of normal
operation.
PiperOrigin-RevId: 510405347
Change-Id: I0b3ea390de97014cfa353079ae2e0c1c637aca69
std::chrono methods used by std::condition_variable.
A followup change will add an implemention of
synchronization_internal::Waiter that can use
std:mutex/std::condition_variable to implement the per-thread
semaphore that absl::Mutex waits on. This implementation may at some
point become the default on platforms such as Windows where there
doesn't seem to be an easy way of supporting real absolute timeouts. In
this case we can defer to their standard library to implement correct
support.
PiperOrigin-RevId: 510204786
Change-Id: Icf4d695013fd060abbd53dae23e71ea36f731565
APIs that take KernelTimeout as a parameter can now query if an
absolute or relative timeout was requested. If the underlying API can
only use one type of timeout, the code will do a reasonable
conversion.
The goal is to eventually enable the possibility of using wait times
that are based on monotonic clocks that are safe against system clock
steps.
PiperOrigin-RevId: 508541507
Change-Id: Id08bf13515f3e1bfd78d88393cde98a6fd3ef72c
