нюансы 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]

установка времени юзером входит в штатные настройки устройства.

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

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

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

Сообщение отредактировал sasamy - Sep 17 2013, 19:54