Синхронизация потоков, ... Опции

[Гость_Гость_Алексей_*_*]

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

я в многозадачность некогда не лез раньше... но походу пора уже..
читал про mutex но хз.. на сколько оно подойдет здесь


Код не прошу.. прост укажите куда копать пожалуст.

[Iron Bug]

есть у буста в документации по boost::thread раздел синхронизация потоков. это базовая документация по всем видам синхронизации в бусте (для потоков).

в данном случае ты можешь применить условные переменные (condition variables) или барьеры (barriers). барьеры проще(тут их вполне достаточно будет), условные переменные - универсальней.

но вообще, какой смысл запускать функцию в отдельном потоке, если ты всё равно ждёшь её завершения? тут какая-то чисто логическая ошибка. либо ты что-то недопонял, либо не так сформулировал.
обычно потоки используются для параллельного выполнения задач.

Сообщение отредактировал Iron Bug - 11.4.2012, 8:37

[Гость_Гость_Алексей_*_*]

У меня окно создаться на glut для дебага объектов из основного(оно показывает положения, пересечения и тп..)
у glut последняя функция блочит поток.. и начинается обработка событий glut.

в общем в release glut не будет.. прога консольная... работает через сетку... поэтому таймеры и т.п. работают через io_service boost

ну и естественно при дебаге функция рисования и изменения данных не должны отрабатываться параллельно

в общем такая история)
Спасибо почитаю...

[Гость_Гость_Алексей_*_*]

В общем если кому интересно(что вряд ли) сделал через boost::barrier и
boost::signal0 для вызова из основного кода события перерисовки... всё начало работать... но тупить страшно..) мож гдето и накасячил когда изврашялься с glut....

в общем понял что и даже для дебага такое извращение обработки событий не очень подходит..
Нашел альтернативу glut в которой система не вешается по вызову функции.... инсталлировать окно через SDL там обработка событий идет в цикле как на winApi.... и можно обрабатывать всё это в io_service..


Iron Bug, спасибо за помощь, как не напишу всё время от тебя ответы идут...

[Iron Bug]

как не напишу всё время от тебя ответы идут

просто мало кто с бустом тут общается плотно. а я его уже много лет юзаю успешно.

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