Для отработки таймаута в коммуникационных протоколах удобно использовать sem_timedwait() а возможно и pthread_mutex_timedwait(). Но у этих функций есть нюанс: они используют время CLOCK_REALTIME которое может быть изменено пользователем или NTP. Когда время меняется таймауты искажаютя и протокол сбивается с чем я и столкнулся.
Строго говоря если юзер может сам задавать время то CLOCK_REALTIME следует рассматривать как случайную величину и естественно никакие таймауты на него вешать нельзя. Для этого в линуксе давно придумано CLOCK_MONOTONIC_RAW.
Проблема зарегистрирована как Bug 14717 - Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait()
и обсуждалась Why only CLOCK_REALTIME time-outs for POSIX semaphores and mutexes?
Обсуждение по второй ссылке феерически тупое. До народа никак не доходит что часы намеренно / по ошибке / с бодуна могут быть установлены в произвольное состояние. Как говорится "тупыы-е".

Как вы в своих программах решаете вопрос таймаутов при скачках времени ?

А если юзер имеет права на запись на диск с корневой ФС то вообще пипец - ага, на нем никакие данные хранить нельзя.



в чем проблема - исключите такие ошибки.

О, еще один из пиндостана подгреб.
Запись на диск с корневой ФС по команде пользователя в устройстве не предусмотрена а установка времени юзером входит в штатные настройки устройства. Кроме того работает синхронизация времени с NTP сервером. Я не отвечаю за работу стороннего сервера. Что если юзер пропишет адрес сервера который отдает время в XVII веке ? Да юзер идиот и придурок но он платит деньги и за косяки моего устройства отвечать мне а не придурку.


Алгоритм проверки валидности времени при отстутсвии связи с внешним миром в студию пожалуйста.

Linux должен проверять что этот юзер не сбодуна время устанавливает ? К чему вообще претензии ?



По вашей ссылке "тупые" написали совет - запускать процесс после синхронизации времени. Так что алгоритм даже детсадовец напишет - сначала синхронизировать время а потом запускать критичный к точному времени процесс(ы). Если нет связи с внешним миром то никак вы его не проверите - хоть уср-сь. Единственный вариант который вижу - не делать резервного питания на RTC и после старта всегда будете иметь определнное значение которое легко распознать как невалидное потому что оно даже на момент написания ПО уже будет из прошлого.

Это кстати элементарно решается ведением технологического лога где фиксируются все изменения внесенные в настройки с указанием кто внес изменения - оператор или сама система. На приборах коммерческого учета энергоресурсов именно так и делают потому что неучтенка за 1 час на точке учета с нагрузкой скажем мегаватт 50 выливается в круглую сумму. Еще такой нюанс - лет пять назад (сейчас я не в теме - может что-то изменилось) в РФ нельзя было брать точное время для коммерческого учета (не было сертифицированных серверов времени) из Интернет, единственный вариант - это GPS или Глонасс, да и то иногда требовали чтобы приемник был внесен в госреестр что в принципе бред - сам приемник не является средством измерения и приходилось покупать "навигацинный прибор" за какие-то немыслимые суммы. Так что к установке времени надо относиться трепетно

Мой прибор не является средством учета и запросто мог бы функционировать без времени, то что в логах будет левое время - с этим пусть разбирается пользователь. Проблема вообще в другой плоскости. Относительные таймауты не должны никак зависеть от реального времени. В ядре же нет привязки к реальному времени, все замечательно функционирует по системному таймеру. Нужно то же только в юзерспейсе.
Вот в QNX головой пользуются и предусмотрели sem_timedwait_monotonic() и ей подобное.

Хороший вопрос по REALTIME_CLOCK. Я как-то тоже использовал этот таймер для организации паузы и тоже была мысль насчёт перевода времени. К счастью, в том софте это никак бы не отразилось на работе софта. С другой стороны, в ucOS я тоже решил реализовать чтение и установку времени и там тоже встал вопрос о переводе времени, на этот раз серьёзнее. Я сделал так, что есть коллбэк на системный тик, а системное время соответствует некоторому количеству тиков. Соответственно можно получать/устанавливать системное время, а необходимые задержки для потоков получать от тиков, а не от системного времени.
Можно попробовать воспроизвести этот подход в вашем случае.

это и есть подобие CLOCK_MONOTONIC_RAW

Ситуация обстоит следующим образом.

Есть стандарт POSIX, в котором указано, что timed_wait функции используют CLOCK_REALTIME. Есть другой стандарт POSIX (ADVANCED REALTIME), в котором ввели выбор clocksource для кондваров (pthread_condattr_setclock). Причем обязательно должен поддерживаться CLOCK_REALTIME, а CLOCK_MONOTONIC и пр. источники - опциональны. Так что вопрос к авторам стандарта, а не разработчикам сишных библиотек или ядра.

Решаются данные проблемы незамысловато: через не-POSIX интерфейсы

Например, в ядре linux задается относительное время, а в QNX, где драйверы исполняются как пользовательские процессы, ввели свои расширения - pthread_mutex_timedlock_monotonic(), sem_timedwait_monotonic() и т.п. Другими словами, код, зависящий от таких таймаутов считается драйверным и должен находиться в ядре/драйверах, а не в юзерспейсе (где со временем совсем туго) и не использовать POSIX. Примерно так.

Почему в POSIX добавили CLOCK_MONOTONIC только для кондваров и обделили семафоры и мьютексы - другой вопрос, и тоже весьма интересный. Думаю, тут дело в функциональном назначении этих примитивов.

EDIT: Как вариант, можете самостоятельно реализовать подобные расширения для юзерспейса, типа тех же pthread_mutex_timedlock_monotonic() и пр.

А вот тут этот вопрос и рассматривается: