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