Многопоточный каркас приложения C или шаблон - PullRequest
5 голосов
/ 28 февраля 2012

Я некоторое время работал над многопоточным приложением C (Linux) - видеомагнитофоном, в котором есть потоки для захвата, кодирования, мультиплексирования и записи аудио и видео.

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

Пока что я придумал что-то вроде этого:

  • У каждого потока должна быть блокировка мьютекса и два условия - одно для пробуждения потока, а другое для сигнализации о том, что поток завершил выполнение некоторой работы, которую может ожидать другой поток.
  • Очереди данных «принадлежат» определенному потоку и защищены с помощью блокировки этого потока.
  • Каждый поток нуждается в понятии «активные» и «неактивные» состояния и способности перемещаться между ними и сигналом, когда все готово.

Я планирую хранить общие элементы в структуре и иметь массив тех структур, которые я могу перебрать для запуска, проверки и остановки всех потоков.

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

1 Ответ

4 голосов
/ 28 февраля 2012

Ваши идеи напоминают мне модель активных объектных вычислений, реализованную в структурах конечного автомата QP.В частности, платформы QP / C и QP / C ++ были портированы на POSIX (который включает в себя Linux, BSD и т. Д.).Этот порт подробно описан в примечании по применению «QP и Linux», доступном по адресу: http://www.state -machine.com / linux / AN_QP_and_Linux.pdf .

Вот основные моментыпорт QP для Linux:

  • Каждый конечный автомат выполняется в своем собственном p-потоке.P-поток блокирует очередь событий, реализованную с помощью мьютекса и условной переменной.Когда очередь событий получает событие, поток разблокируется, и событие обрабатывается конечным автоматом, связанным с этим потоком.(Это хорошо известная модель вычисления активного объекта.)

  • Очереди событий принадлежат потокам активного объекта.

  • Каждый поток имеет целоеиерархический конечный автомат, поэтому он может иметь состояния «активный» или «неактивный». Иерархические конечные автоматы (диаграммы состояний UML) позволяют указывать действия и переходы в состоянии более высокого уровня и повторное использование этого поведения во вложенных состояниях.Это противодействует "взрыву" переходов между состояниями, которые вы имеете с традиционными автоматами.

...