gnulinux: use CLOCK_MONOTONIC for periodic tasks (fix #105) #138
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
|
Merged to toolchain-2.9 branch in f6017b0. |
|
Note that this patch is not effective anymore in combination with #91. |
meyerj
added a commit
to meyerj/rtt
that referenced
this pull request
Mar 1, 2018
The absolute time returned by rtos_get_time_ns() or RTT::os::TimeService::getNSecs() was generated from a wall clock (time of day), which is not monotonic and can jump in certain cases, e.g. due to an NTP update. This time is used in several internal and public API functions to implement timers or to wait on a condition variable, mutex or semaphore with a timeout. In all these cases non-steady system time can have undesirable side effects, which are not expected in a Real-Time Toolkit. There have been several attempts to fix or at least mitigate that problem: - http://bugs.orocos.org/show_bug.cgi?id=735 - orocos-toolchain#129 - orocos-toolchain#138 This patch introduces some potentially breaking changes: - Use clock_gettime(CLOCK_MONOTONIC, ...) to implement rtos_get_time_ns() for the gnulinux target. This change has a major impact on all usages of that method, rtos_get_ticks() or the higher-level methods RTT::os::TimeService::getNSecs() and RTT::os::TimeService::getTicks(), whose return values cannot be interpreted as wall time anymore. - Consequently remove the rtos_get_time_monotonic-ns() function introduced in orocos-toolchain#138. - Drop RTT::os::Semaphore::waitUntil() and the underlying OS abstraction functions. The only usage within the RTT core was in RTT::os::Timer, which can easily be rewritten using condition variables. POSIX semaphores do not support waiting with an absolute timeout from the monotonic clock. - Added new OS abstraction functions for waiting on a mutex lock with a relative timeout. POSIX does not provide a pthread_mutexattr_setclock() method similar to pthread_condattr_setclock(). For that reason rtos_mutex_lock_until() and rtos_mutex_trylock_for() are currently falling back to CLOCK_REALTIME.
meyerj
added a commit
to meyerj/rtt
that referenced
this pull request
Mar 1, 2018
The absolute time returned by rtos_get_time_ns() or RTT::os::TimeService::getNSecs() was generated from a wall clock (time of day), which is not monotonic and can jump in certain cases, e.g. due to an NTP update. This time is used in several internal and public API functions to implement timers or to wait on a condition variable, mutex or semaphore with a timeout. In all these cases non-steady system time can have undesirable side effects, which are not expected in a Real-Time Toolkit. There have been several attempts to fix or at least mitigate that problem: - http://bugs.orocos.org/show_bug.cgi?id=735 - orocos-toolchain#129 - orocos-toolchain#138 This patch introduces some potentially breaking changes: - Use clock_gettime(CLOCK_MONOTONIC, ...) to implement rtos_get_time_ns() for the gnulinux target. This change has a major impact on all usages of that method, rtos_get_ticks() or the higher-level methods RTT::os::TimeService::getNSecs() and RTT::os::TimeService::getTicks(), whose return values cannot be interpreted as wall time anymore. - Consequently remove the rtos_get_time_monotonic-ns() function introduced in orocos-toolchain#138. - Drop RTT::os::Semaphore::waitUntil() and the underlying OS abstraction functions. The only usage within the RTT core was in RTT::os::Timer, which can easily be rewritten using condition variables. POSIX semaphores do not support waiting with an absolute timeout from the monotonic clock. - Added new OS abstraction functions for waiting on a mutex lock with a relative timeout. POSIX does not provide a pthread_mutexattr_setclock() method similar to pthread_condattr_setclock(). For that reason rtos_mutex_lock_until() and rtos_mutex_trylock_for() are currently falling back to CLOCK_REALTIME. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
meyerj
added a commit
to Intermodalics/rtt
that referenced
this pull request
Mar 1, 2018
The absolute time returned by rtos_get_time_ns() or RTT::os::TimeService::getNSecs() was generated from a wall clock (time of day), which is not monotonic and can jump in certain cases, e.g. due to an NTP update. This time source is used in several internal and public API functions to implement timers or to wait on a condition variable, mutex or semaphore with a timeout. In all these cases non-steady system time can have undesirable side effects, which are not expected in a Real-Time Toolkit. There have been several attempts to fix or at least mitigate that problem: - http://bugs.orocos.org/show_bug.cgi?id=735 - orocos-toolchain#129 - orocos-toolchain#138 This patch introduces some potentially breaking semantic changes, with only minimal changes to the public API: - Use clock_gettime(CLOCK_MONOTONIC, ...) to implement rtos_get_time_ns() for the gnulinux target. This change has a major impact on all usages of that method, rtos_get_ticks() or the higher-level methods RTT::os::TimeService::getNSecs() and RTT::os::TimeService::getTicks(), whose return values cannot be interpreted as wall time anymore. - Consequently remove the rtos_get_time_monotonic_ns() function introduced in orocos-toolchain#138. - Drop RTT::os::Semaphore::waitUntil() and the underlying OS abstraction functions. The only usage within the RTT core was in RTT::os::Timer, which can be rewritten using a condition variable. POSIX semaphores do not support waiting with an absolute timeout from the monotonic clock. - Add new OS abstraction functions for waiting on a mutex lock with a relative timeout and use them to implement RTT::os::Mutex::timedlock(). POSIX does not provide a pthread_mutexattr_setclock() method similar to pthread_condattr_setclock(). For that reason rtos_mutex_lock_until() and rtos_mutex_trylock_for() have to fall back to CLOCK_REALTIME and may still be affected by time adjustments while waiting. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
meyerj
added a commit
to Intermodalics/rtt
that referenced
this pull request
Mar 1, 2018
The absolute time returned by rtos_get_time_ns() or RTT::os::TimeService::getNSecs() was generated from a wall clock (time of day), which is not monotonic and can jump in certain cases, e.g. due to an NTP update. This time source is used in several internal and public API functions to implement timers or to wait on a condition variable, mutex or semaphore with a timeout. In all these cases non-steady system time can have undesirable side effects, which are not expected in a Real-Time Toolkit. There have been several attempts to fix or at least mitigate that problem: - http://bugs.orocos.org/show_bug.cgi?id=735 - orocos-toolchain#129 - orocos-toolchain#138 This patch introduces some potentially breaking semantic changes, with only minimal changes to the public API: - Use clock_gettime(CLOCK_MONOTONIC, ...) to implement rtos_get_time_ns() for the gnulinux target. This change has a major impact on all usages of that method, rtos_get_ticks() or the higher-level methods RTT::os::TimeService::getNSecs() and RTT::os::TimeService::getTicks(), whose return values cannot be interpreted as wall time anymore. - Consequently remove the rtos_get_time_monotonic_ns() function introduced in orocos-toolchain#138. - Drop RTT::os::Semaphore::waitUntil() and the underlying OS abstraction functions. The only usage within the RTT core was in RTT::os::Timer, which can be rewritten using a condition variable. POSIX semaphores do not support waiting with an absolute timeout from the monotonic clock. - Add new OS abstraction functions for waiting on a mutex lock with a relative timeout and use them to implement RTT::os::Mutex::timedlock(). POSIX does not provide a pthread_mutexattr_setclock() method similar to pthread_condattr_setclock(). For that reason rtos_mutex_lock_until() and rtos_mutex_trylock_for() have to fall back to CLOCK_REALTIME and may still be affected by time adjustments while waiting. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR applies the patch proposed by @rbrtslmn in #105.
It switches to use a monotonic clock source for periodic waiting in the gnulinux target, but it is also somehow incomplete because it does not fix the same issue for other broken targets (like MacOS), for waiting on condition variables and for RTT Timers.