[_3m 4]

Для отработки таймаута в коммуникационных протоколах удобно использовать 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 11]

Строго говоря если юзер может сам задавать время то 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 4]

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

О, еще один из пиндостана подгреб.

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

 

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

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

 

[sasamy 11]

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

 

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

 

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

 

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

Изменено 17 сентября, 2013 пользователем sasamy

[sasamy 11]

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

 

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

[_3m 4]

...

Так что к установке времени надо относиться трепетно :)

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

Вот в QNX головой пользуются и предусмотрели sem_timedwait_monotonic() и ей подобное.

[andrewlekar 0]

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

Можно попробовать воспроизвести этот подход в вашем случае.

[psL 0]

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

Можно попробовать воспроизвести этот подход в вашем случае.

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

[vshemm 0]

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

 

Есть стандарт 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() и пр. :)

 

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

It was decided that the features of CLOCK_MONOTONIC are not as critical to these functions as they are to pthread_cond_timedwait(). The pthread_cond_timedwait() function is given a relative timeout; the timeout may represent a deadline for an event. When these functions are given relative timeouts, the timeouts are typically for error recovery purposes and need not be so precise.

 

Therefore, it was decided that these functions should be tied to CLOCK_REALTIME and not complicated by being given a choice of clock.

Изменено 18 сентября, 2013 пользователем vshemm