нюансы sem_timedwait() Опции

[_3m]

Для отработки таймаута в коммуникационных протоколах удобно использовать 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?
Обсуждение по второй ссылке феерически тупое. До народа никак не доходит что часы намеренно / по ошибке / с бодуна могут быть установлены в произвольное состояние. Как говорится "тупыы-е".

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

[sasamy]

Строго говоря если юзер может сам задавать время то CLOCK_REALTIME следует рассматривать как случайную величину и естественно никакие таймауты на него вешать нельзя.

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

До народа никак не доходит что часы намеренно / по ошибке / с бодуна могут быть установлены в произвольное состояние.

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

Sufficiently recent versions of glibc and the Linux kernel support the following clocks:

CLOCK_REALTIME
System-wide real-time clock. Setting this clock requires appropriate privileges.

[_3m]

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

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

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

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

[sasamy]

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

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