День добрый.
После переезда на nptl стала появляться бага "busy loop".
Идея кода: случается нажатие кнопки (взводим событие и задаем abstime) и до тех пор пока ее не отпустили имитируется ее нажате.
Код такой:
pthread_mutex_lock(&mutex);
while (1)
{
// if we don't have any deadline, then just sleepif ( 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 причин.
Здравствуйте, 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 ли?
Спасибо за ответ!
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 причин.
Здравствуйте, 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 причин.
Здравствуйте, 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>День добрый. k55>После переезда на nptl стала появляться бага "busy loop".
А мютекс случаем не мембер объекта? Если так то такой объект не должен копироваться вообще, т.к. объекты синхронизации обычно "некопируемые".
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, ilnar, Вы писали:
k55>>и когда tv_nsec становилось равным 1000000000 все ломалось.
I>ай яй яй, я тебе еще 17.09.12 16:16 сказал поставить проверку условия перед входом в pthread_cond_timedwait и можно было бы упасть с коркой
Понадеялся на проверку которая уже была сделана. Но не обратил внимание на строгость неравенства.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
ну и как следствие все остальное мрет. Срабатывает ватч дог и все умирают 
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
