Pthread_cond_timedwait: проблема, решение, дискуссия

Здравствуйте, уважаемые Хабраюзеры!

Продолжая серию постов по многопоточному программированию, хочется коснуться одной фундаментальной проблемы использования сигнальных переменных в Linux, к сожалению, не имеющей пока красивого универсального решения (а может оно просто неизвестно мне). Многие, к сожалению, даже не догадываются о том, что такая проблема имеет место быть.

Рассмотрим простой пример использования сигнальной переменной:

struct timeval now; struct timespec timeout; gettimeofday(&now, 0); timeout.tv_sec = now.tv_sec + 2;      // 2 sec timeout.tv_nsec = now.tv_usec * 1000; // nsec  retval=0; pthread_mutex_lock(&mutex); while(!somethingHappens() && retval==0) {     retval=pthread_cond_timedwait(&condition, &mutex, &timeout); } pthread_mutex_unlock(&mutex); 

Смысл использования pthread_cond_timedwait состоит в том, что мы либо дожидаемся получения сигнала (pthread_cond_signal или pthread_cond_broadcast) в качестве уведомления о том, что somethingHappens(), или же прекращаем ожидание по истечении заданного нами таймаута. Во второй части фразы и кроется та самая потенциальная проблема! Обратите внимание, что время, передаваемое в качестве третьего параметра в pthread_cond_timedwait, задается в абсолютном виде! А что, если время будет переведено назад(!) после того, как мы получим текущее время (gettimeofday) и до того, как уснем в ожидании на pthread_cond_timedwait?

Каково будет поведение pthread_cond_timedwait, если наш процесс уже спит на этом вызове? Здесь все чисто! На всех платформах, на которых я проводил эксперимент с переводом времени назад, изменение просто игнорировалось, т.е. реально внутри вызова время все-таки преобразуется из абсолютного к относительному значению. Интересно, почему это не вынесено в интерфейс функции? Это бы решило все проблемы!

Критики могут возразить, что это какая-то пренебрежимо маловероятная ситуация, чтобы перевод системного времени попал именно в этот ничтожно малый кусок кода. Позвольте не согласиться. С одной стороны, если вероятность какого-либо события не равна нулю, то оно обязательно случится (принято называть это «генеральским эффектом»), а с другой стороны все сильно зависит от конкретной программы. Мы столкнулись с этой проблемой при разработке системы видеонаблюдения, а это десятки потоков (thread-ов), в каждом из которых делается pthread_cond_timedwait раз эдак 25 в секунду, а перевод времени на час назад приводил к тому, что с вероятностью, близкой к 100%, какой-нибудь поток да и заснет на этот час плюс 1/25 секунды!

Что делать?

Как я уже сказал в начале своего повествования, красивого решения данной проблемы нет, но и не решать ее вовсе, нельзя! В нашей системе мы организовали отдельный поток, назовем его «потоком мониторинга системного времени», который отслеживает «переводы времени назад» и в случае их выявления «будит» все сигнальные переменные. Т.е. по сути, решение предполагает наличие в системе некоторого выделенного менеджера, в котором необходимо зарегистрировать все используемые сигнальные переменные. Получилось что-то такое:

class SystemTimeManager { public:     SystemTimeManager();     ~SystemTimeManager();      void registerCond(pthread_mutex_t *mutex, pthread_cond_t *cond);     void unregisterCond(pthread_cond_t *cond);  private:     static void *runnable(void *ptr);  private:     time_t _prevSystemTime;     pthread_t _thread;     bool _finish;     pthread_mutex_t _mutex;     std::map<pthread_cond_t *, pthread_mutex_t *> _container; };  SystemTimeManager::SystemTimeManager ():     _prevSystemTime(time(0)),     _finish(false) {     pthread_mutex_create(&_mutex, 0);     pthread_create(&_thread, 0, runnable, this); }  SystemTimeManager::~SystemTimeManager() {     _finish=true;     pthread_join(_thread, 0);     pthread_mutex_destroy(&_mutex); }  void SystemTimeManager::registerCond(pthread_mutex_t *mutex, pthread_cond_t *cond) {     pthread_mutex_lock(&_mutex);     _container.insert(std::make_pair(cond, mutex));     pthread_mutex_unlock(&_mutex); }  void SystemTimeManager::unregisterCond(pthread_cond_t *cond) {     pthread_mutex_lock(&_mutex);     std::map<pthread_cond_t *, pthread_mutex_t *> it=_container.find(cond);     if(it!=_container.end())         _container->erase(it);     pthread_mutex_unlock(&_mutex); }  void * SystemTimeManager::runnable(void *ptr) {     SystemTimeManager *me=reinterpret_cast< SystemTimeManager *>(ptr);     while(!_finish)     {         If(time(0)<_prevSystemTime)         {             pthread_mutex_lock(&me->_mutex);             for(std::map<pthread_cond_t *, pthread_mutex_t *> it=_container.begin();                  it!=_container.end(); ++it)             {                  pthread_mutex_lock(it->second);                  pthread_cond_broadcast(it->first);                  pthread_mutex_unlock(it->second);             }             pthread_mutex_unlock(&me->_mutex);         }         _prevSystemTime=time(0);     } } 

Теперь нам достаточно создать экземпляр класса SystemTimeManager и не забыть зарегистрировать в нем все используемые нами сигнальные переменные.

В заключение хотелось бы обратить внимание уважаемого сообщества на тему данной статьи «проблема, решение, дискуссия». Проблему, я надеюсь, описал достаточно понятно. Решение описанной проблемы, пусть и не самое элегантное, я привел – надеюсь, оно кому-нибудь будет полезно. Однако последнее – дискуссию — я никак не могу сделать без вас, уважаемые Хабраюзеры. Может быть, у кого-то есть какие-то другие, более элегантные решения данной проблемы?