проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 13.09.12 08:27
Оценка:
День добрый.
После переезда на nptl стала появляться бага "busy loop".

Идея кода: случается нажатие кнопки (взводим событие и задаем abstime) и до тех пор пока ее не отпустили имитируется ее нажате.
Код такой:
    pthread_mutex_lock(&mutex);
    while (1)
    {
        // if we don't have any deadline, then just sleep
        if ( abstime.tv_sec == 0 && abstime.tv_nsec == 0 )
        {
            pthread_cond_wait(&cond, &mutex);
        }
        else
        {
            int rc;
            rc = pthread_cond_timedwait(&cond, &mutex, &abstime);
            if (rc == ETIMEDOUT)
            {
               //do some
            }
        }
    }


Иногда поток который исполняет этот код начинает жрать процессорное время до 40% ну и как следствие все остальное мрет. Срабатывает ватч дог и все умирают

Есть у кого идеи?

p.s. Погуглил и нашел вот это
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673711
но ввиду своей ограниченности не могу понять
1) есть ли эта бага в glibc 2.12.2 который я использую? Если что архитектура mips, ядро 2.6.37
2) если 1) истина, то где найти патч и пофиксить glibc. Использовать свежий glibc — вопрос решаемый не мной и не мгновенно.


Спасибо!
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re: проблемы с pthread_cond_timedwait
От: ilnar Россия  
Дата: 13.09.12 09:31
Оценка:
Здравствуйте, k55, Вы писали:

k55>День добрый.

k55>После переезда на nptl стала появляться бага "busy loop".

k55>Идея кода: случается нажатие кнопки (взводим событие и задаем abstime) и до тех пор пока ее не отпустили имитируется ее нажате.

k55>Код такой:
k55>
k55>    pthread_mutex_lock(&mutex);
k55>    while (1)
k55>    {
k55>        // if we don't have any deadline, then just sleep
k55>        if ( abstime.tv_sec == 0 && abstime.tv_nsec == 0 )
k55>        {
k55>            pthread_cond_wait(&cond, &mutex);
k55>        }
k55>        else
k55>        {
k55>            int rc;
k55>            rc = pthread_cond_timedwait(&cond, &mutex, &abstime);
k55>            if (rc == ETIMEDOUT)
k55>            {
k55>               //do some
k55>            }
k55>        }
k55>    }
k55>


k55>Иногда поток который исполняет этот код начинает жрать процессорное время до 40% ну и как следствие все остальное мрет. Срабатывает ватч дог и все умирают


k55>Есть у кого идеи?


k55>p.s. Погуглил и нашел вот это

k55>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673711
k55>но ввиду своей ограниченности не могу понять
k55>1) есть ли эта бага в glibc 2.12.2 который я использую? Если что архитектура mips, ядро 2.6.37
k55>2) если 1) истина, то где найти патч и пофиксить glibc. Использовать свежий glibc — вопрос решаемый не мной и не мгновенно.


k55>Спасибо!


0. посмотри, правильно ли формируешь abstime -- это должно быть время в будущем, до которого ожидать, а не сколько времени ожидать. Например, для ожидания почти 3-х сек (2-3 сек), так: abstime.tv_sec = time(0) + 3; abstime.tv_nsec = 0;
1. трассируй выполнение: strace, в твоем случае скорее нужен ltrace
2. посмотри, какой код ошибки возвращается, ETIMEDOUT ли?
Re[2]: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 13.09.12 11:25
Оценка:
Здравствуйте, ilnar, Вы писали:

Спасибо за ответ!

I>0. посмотри, правильно ли формируешь abstime -- это должно быть время в будущем, до которого ожидать, а не сколько времени ожидать. Например, для ожидания почти 3-х сек (2-3 сек), так: abstime.tv_sec = time(0) + 3; abstime.tv_nsec = 0;

Угу, правильно задается.

I>1. трассируй выполнение: strace, в твоем случае скорее нужен ltrace

I>2. посмотри, какой код ошибки возвращается, ETIMEDOUT ли?
Логов добавил. Результаты будут завтра.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[2]: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 17.09.12 12:02
Оценка:
Здравствуйте, ilnar, Вы писали:

I>0. посмотри, правильно ли формируешь abstime -- это должно быть время в будущем, до которого ожидать, а не сколько времени ожидать. Например, для ожидания почти 3-х сек (2-3 сек), так: abstime.tv_sec = time(0) + 3; abstime.tv_nsec = 0;

I>1. трассируй выполнение: strace, в твоем случае скорее нужен ltrace
I>2. посмотри, какой код ошибки возвращается, ETIMEDOUT ли?

Логи показали что ошибка 22 — EINVAL.

В коде __pthread_cond_timedwait явно вижу только одно место:


  if (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)
    return EINVAL;


Вопрос, может ли __pthread_mutex_unlock_usercnt вернуть EINVAL?
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[3]: проблемы с pthread_cond_timedwait
От: ilnar Россия  
Дата: 17.09.12 12:16
Оценка:
Здравствуйте, k55, Вы писали:

k55>Здравствуйте, ilnar, Вы писали:


I>>0. посмотри, правильно ли формируешь abstime -- это должно быть время в будущем, до которого ожидать, а не сколько времени ожидать. Например, для ожидания почти 3-х сек (2-3 сек), так: abstime.tv_sec = time(0) + 3; abstime.tv_nsec = 0;

I>>1. трассируй выполнение: strace, в твоем случае скорее нужен ltrace
I>>2. посмотри, какой код ошибки возвращается, ETIMEDOUT ли?

k55>Логи показали что ошибка 22 — EINVAL.


k55>В коде __pthread_cond_timedwait явно вижу только одно место:



k55>
k55>  if (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)
k55>    return EINVAL;

k55>


ну вот, сделай код предпроверки и исправления такой ситуации.


k55>Вопрос, может ли __pthread_mutex_unlock_usercnt вернуть EINVAL?

не знаю, не понял к чему вопрос
Re: проблемы с pthread_cond_timedwait
От: ДимДимыч Украина http://klug.org.ua
Дата: 17.09.12 12:19
Оценка:
Здравствуйте, k55, Вы писали:

k55>Есть у кого идеи?


mutex и cond инициализируются перед использованием?
http://files.rsdn.org/25994/sign.gif Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[4]: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 17.09.12 13:42
Оценка:
Здравствуйте, ilnar, Вы писали:


k55>>Вопрос, может ли __pthread_mutex_unlock_usercnt вернуть EINVAL?

I>не знаю, не понял к чему вопрос

Это метод внутри pthread_... который может вернуть ошибку.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[2]: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 17.09.12 14:36
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Здравствуйте, k55, Вы писали:


k55>>Есть у кого идеи?


ДД>mutex и cond инициализируются перед использованием?


да, все инициализируется и большую часть времени все рабоатет нормально, но иногда начинает возвращать ошибку 22.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[3]: проблемы с pthread_cond_timedwait
От: ДимДимыч Украина http://klug.org.ua
Дата: 17.09.12 15:48
Оценка:
Здравствуйте, k55, Вы писали:

k55>да, все инициализируется и большую часть времени все рабоатет нормально, но иногда начинает возвращать ошибку 22.


Тогда тут два варианта: либо кто-то портит память и затирает mutex, cond или abstime, либо abstime вычисляется неправильно.
http://files.rsdn.org/25994/sign.gif Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re: проблемы с pthread_cond_timedwait
От: Vain Россия google.ru
Дата: 25.09.12 21:37
Оценка:
Здравствуйте, k55, Вы писали:

k55>День добрый.

k55>После переезда на nptl стала появляться бага "busy loop".
А мютекс случаем не мембер объекта? Если так то такой объект не должен копироваться вообще, т.к. объекты синхронизации обычно "некопируемые".
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 01.10.12 09:52
Оценка:
Всем спасибо.

Дело было в abstime.

Из pthread_cond_timedwait выходили по этой проверке:

  if (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)
    return EINVAL;


В рабочем коде была вот такая проверка

if (abstime->tv_nsec > 1000000000)
   ... //уменьшаем tv_nsec


и когда tv_nsec становилось равным 1000000000 все ломалось.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[2]: проблемы с pthread_cond_timedwait
От: ilnar Россия  
Дата: 01.10.12 12:21
Оценка:
Здравствуйте, k55, Вы писали:

k55>Всем спасибо.


k55>Дело было в abstime.


k55>Из pthread_cond_timedwait выходили по этой проверке:


k55>
k55>  if (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)
k55>    return EINVAL;
k55>


k55>В рабочем коде была вот такая проверка


k55>
k55>if (abstime->tv_nsec > 1000000000)
k55>   ... //уменьшаем tv_nsec
k55>


k55>и когда tv_nsec становилось равным 1000000000 все ломалось.


ай яй яй, я тебе еще 17.09.12 16:16 сказал поставить проверку условия перед входом в pthread_cond_timedwait и можно было бы упасть с коркой
Re[3]: проблемы с pthread_cond_timedwait
От: k55 Ниоткуда  
Дата: 01.10.12 18:01
Оценка:
Здравствуйте, ilnar, Вы писали:

k55>>и когда tv_nsec становилось равным 1000000000 все ломалось.


I>ай яй яй, я тебе еще 17.09.12 16:16 сказал поставить проверку условия перед входом в pthread_cond_timedwait и можно было бы упасть с коркой



Понадеялся на проверку которая уже была сделана. Но не обратил внимание на строгость неравенства.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.