condition_variable workaround for wait_until with system time change

Question

I have a timer class which uses the std::condition_variable wait_until (I have also tried wait_for ). I am using the std::chrono::steady_clock time to wait until a specific time in the future.

This is meant to be monotonic, but there has been a long standing issue with this where this actually uses the system clock and fails to work correctly when the system time is changed.

It has been fixed in libc as suggested here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 .

the issue is that this is still pretty new ~2019 and only available in gcc version 10. I have some cross compilers that are only up to gcc version ~8.

I am wandering if there is a way to get this fix into my versions (I have quite a few cross compilers) of gcc? - but this might prove difficult to maintain if I have to re-build the cross compilers each time I update them or such.

So a better question might be, what is a solution to this issue until I can get all my tools up to gcc v10? - how can I make my timer resistant to system time changes?

updated notes

• Rustyx mentions the version of glibc needed is 2.3.0+ (more for my ref - use ldd --version to check that)
• glibc change log showing the relevant entry for the fix supplied by Daniel Langr: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/ChangeLog-2019#L2093
• The required glibc patch (supplied by rustyx): https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=ad4d1d21ad5c515ba90355d13b14cbb74262edd2

Answer 1

1. Create a data structure that contains a list of condition variables each with a use count protected by a mutex.

2. When a thread is about to block on a condition variable, first acquire the mutex and add the condition variable to the list (or bump its use count if it's already on the list).

3. When done blocking on the condition variable, have the thread again acquire the mutex that protects the list and decrement the use count of the condition variable it was blocked on. Remove the condition variable from the list if its use count drops to zero.

4. Have a dedicated thread to watch the system clock. If it detects a clock jump, acquire the mutex that protects the list of condition variables and broadcast every condition variable.

That's it. That solves the problem.

If necessary, you can also add a boolean to each entry in the table and set it to false when the entry is added. If the clock watcher thread hast broadcast the condition variable, have it set the bool to true so the woken threads will know why they were woken.

If you wish, you can just add the condition variable to the list when it's created and remove it from the list when it's destroyed. This will result in broadcasting condition variables no threads are blocked on if the clock jumps, but that's harmless.

Here are some implementation suggestions:

Use a dedicated thread to watch the clock. An easy thing to look at is the offset between wall time and the system's uptime clock.

One simple thing to do is to keep a count of the number of time jumps observed and increment it each time you sense a time jump. When you wait for a condition, you can use the following logic:

1. Note the number of time jumps.
2. Block on the condition.
3. When you wake up, recheck the condition.
4. If the condition isn't satisfied, check the number of time jumps.
5. If the count from 1 and 4 mismatch, handle it as a time jump wakeup.

You can wrap this all up so that there's no ugliness in the calling code. It just becomes another possible return value from your version of wait_for .