Доброе.

Есть приложение, которое должно общаться с девайсами по разным портам. Хочу сделать обращение к каождому порту в отдельном потоке. Т.е. запустить сам поток один раз, а потом в нем выполнять нужные функции по работе с портом. _beginthreadex сразу засовывает функцию на выполнение, что меня не устраивает.

Как я еще могу себе это представить. В поток кидается функция, которая там висит и "ловит" сигналы от ядра приложения: "выполни эту функцию с этими параметрами", ну и посылает сигналы приложению: "функцию выполнил успешно (или ошибкой)". На сколько я понимаю для этой цели необходимо использовать mutex, правда как-то я не совсем понимаю как это работает.

По глупому, если рассуждать, то мне надо все, что находится в определеном namespace выполнять в определенном потоке.

Использовать обертку на Qt не очень хочется в данном случае, ввиду того, что хотелось бы для большей переносимости (приложение должно быть кросплатформенным, понятное дело, что релизация потоков для каждой системы будут различными) оставить на стандартном C++.

Спасибо.

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

Событий в модели можно придумать сколь угодно, на каждое событие определить одно конкретное действие (например, событие на чтение конкретного порта, событие на запись в конкретный порт, событие на синхронный вывод результатов, статистики  и т.п.) 

поэтому перед написанием демона нужно разложить все действия по полочкам и найти минимально возможныое множество таких "примитивных" действий, чем проще - тем лучше.

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

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

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

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

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

функции по теме:

CreateEvent - создание сигнального события
SetEvent - активация события
WaitForSingleObject - ожидание объекта синхронизации (напр., события)
WaitForMultiplyObjects - множественное ожидание объектов синхронизации (напр., событий)
CloseHandle - уничтожение события

В принципе, я себе это так и представлял.
На счет SetEvent's  посмотрю (другие реализации есть, Run-time например). А как подобное в Unix системах реализовывать?

Еще, хотелось бы чтобы сам демон не висел в while(true) а просто ждал сигнала.

можно тупо посылать сообщения потоку через PostThreadMessage, ф в потоке организовать цикл обработки сообщнений 

Для тривиального случая где надо выполнить все что находится в определенном namespace и пофик на внешнюю информацию.



По сути если представить себе IStep как callback метод то вообще не нужно никаких мьютексов и синхронизации.

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




Функция это не простая вещь. Функция может спать сколько угодно и вызывать разные,  в т.ч. нестатические функции через кастинг LPVOID lpParameter.

Тучи потоков, не пройдут, т.к. отправкой команд на устроство должен заниматься один поток, иначе может получиться так, что команда, которая должна выполняться позже придет на устройство раньше. Плюс. Каждая команда взаимосвязана с предыдущей в плане (выполнилась не выполнилась предыдущая, ждать или не ждать выполнения предыдущей команды).


Это как раз и являтся целью.


Это как?