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

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

[andrewlekar]

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