LINUX.ORG.RU

[опять glib glib] Теоретический вопрос


0

0

В соседнем треде нашел решение своей проблемы, но пока искал пробовал разные способы и вот используя один из них у меня возникло недопонимание ситуации. Вопрос теоретический, так что про смысл сего лучше не спрашивать.

Вот код



#include <stdio.h>
#include <gtk/gtk.h>
GCond* my_cond;
GMutex* my_mutex;
void fr(void)
{
my_mutex=g_mutex_new();
my_cond=g_cond_new();
g_mutex_lock(my_mutex);
GTimeVal tm;
tm.tv_sec=15;
tm.tv_usec=1;
if(!g_cond_timed_wait(my_cond,my_mutex,&tm))
printf("%d\n",tm.tv_sec);
g_mutex_unlock(my_mutex);
printf("2\n");
}
int main(void)
{
int b=0;
g_thread_init(NULL);
GThread* p = g_thread_create((gpointer) fr,NULL,TRUE,NULL);


g_thread_join(p);
printf("yes\n");
return 0;
}


Почему не происходит 15сек задержка, но при этом g_cond_timed_wait возвращает FALSE, что свидетельствует о завершение временного интервала?

★★★★★

Потому что ты эту функцию используешь не по назначению. Тебе стоит почитать Стивенса или хотя бы man pthread_cond_wait.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Может перестанем кидаться понтами и почитаем внимательно что я написал? Я знаю, что она используется не по назначению и поэтому даже заметил что вопрос всего лишь теоретический и попросил не говорить мне ничего про его смысл, но ты умудрился в двух моих темах повторить одно и тоже. Ну ладно. Идем в документацию

"Структура GCond является закрытой структурой данных представляющих условие. Потоки могут блокироваться на GCond если они обнаружат определённое ложное условие. Если другие потоки изменяют состояние этого условия они сообщают GCond и тогда ожидающий поток просыпается. "

"Заставляет поток ждать условия пробуждения cond, но _не_ _дольше_ _чем_ _определено_ _параметром_ _abs_time_. Взаимоисключение mutex разблокируется перед отключением и блокируется снова после возобнавления"

То есть исходя из написаного я делаю вывод, что если cond не был разблокирован в другом месте(g_cond_signal()) , то он сам разблокируется по прошествию заданного интервала , но на практике я вижу что он не ждет этого инетвала, а сразу производит разблокировку. Вот я и спрашиваю "Почему?". При чем тут программирование под Unix? Я работаю с glib, читаю их документацию, где вроде все понятно описано, но что оказывает что то что там написано не так уж и очевидно?

Ах да еще, про назначение, я сел изучать glib/gtk буквально вчера/сегодня (до этого лишь начинал читать, но забрасывал), я не нашел сразу решения, попытался найти решение. Нашел вот это, я понимал что оно не совсем подходит для того что я хочу, поэтому я не остановился и нашел верное (g_usleep()), так что не стоит мне тут вешать лапшу на уши.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

>"Заставляет поток ждать условия пробуждения cond, но _не_ _дольше_ _чем_ _определено_ _параметром_ _abs_time_. Взаимоисключение mutex разблокируется перед отключением и блокируется снова после возобнавления"

Это про g_cond_timed_wait();

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Не знаю чего ты там изучал и чего ты там читал, но делать надо так:


GTimeVal tm;
-tm.tv_sec=15;
-tm.tv_usec=1;
+g_get_current_time(&tm);
+tm.tv_sec+=15;

Reset ★★★★★
()
Ответ на: комментарий от Reset

И правда работает, спасибо за рахъяснения ситуации.

Просто такое описание

gboolean g_cond_timed_wait (GCond *cond, GMutex *mutex, GTimeVal *abs_time);

abs_time : GTimeVal, определяющая максимальное время ожидания.

Ввело меня в заблуждение.

Для простоты вычисления abs_time может использоваться комбинация g_get_current_time() и g_time_val_add().

А вот эту часть я действительно по дурости не воспринял, потому что счел формулировку "для простоты" не обязательной...

Вопрос снят, спасибо.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

кстати, инициализировать глобальных мьютекс *внутри* поточной функции не стоит даже в тестовом коде с одним потоком. // с глиб-гтк не знаком

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.