Многопоточная диспетчеризация событий - PullRequest
3 голосов
/ 02 апреля 2011

Я занимаюсь разработкой приложения на C ++, которое будет использовать скрипты Lua для внешних надстроек.Дополнения полностью ориентированы на события;обработчики регистрируются в хост-приложении, когда скрипт загружается, и хост вызывает обработчики, когда происходят события.

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

Ответы [ 3 ]

3 голосов
/ 02 апреля 2011

Вот некоторые из них:

  1. Если вы не предпримете для этого определенных шагов, вы не будете контролировать время жизни потоков (они могут работать бесконечно долго) или ресурсы, которые они потребляют (процессор и т. Д.)
  2. Обмен сообщениями между потоками и синхронизированный доступ к общедоступным данным будет сложнее реализовать
  3. Если вы ожидаете большое количество надстроек, издержки на создание потока для каждого из них могут быть слишком большими

Вообще говоря, предоставление управляемым событиями API новым потоком для запуска кажется мне плохим решением. Почему работают потоки, когда им нечего делать, пока не будет инициировано событие? Рассмотрим порождение одного потока для всех надстроек и управление всем распространением событий из этого потока. Это будет значительно легче реализовать, и когда появятся ошибки, у вас будет шанс на победу.

2 голосов
/ 02 апреля 2011

Создание новой темы и ее частое уничтожение - не очень хорошая идея. Во-первых, у вас должен быть способ связать это так, чтобы он не занимал слишком много памяти (например, подумайте о стековом пространстве), или дойти до точки, где происходит много упреждений, потому что потоки конкурируют за время на процессор. Во-вторых, вы потратите много времени на создание новых потоков и их разрушение. (Это зависит от вашей операционной системы. Некоторые ОС могут создавать дешевые потоки, а другие могут быть дорогими.)

Звучит так, как будто вы хотите реализовать рабочую очередь. Я не смог найти хорошую статью в Википедии по этому вопросу, но это близко: Шаблон пула потоков .

Можно часами говорить о том, как реализовать это, и о различных алгоритмах параллельной очереди, которые можно использовать. Но идея в том, что вы создаете N потоков, которые истощают очередь, и выполняете некоторую работу в ответ на поставленные в очередь элементы. Как правило, вы также хотите, чтобы потоки, скажем, ожидали семафор , пока в очереди нет элементов - рабочие потоки уменьшают этот семафор, а перехватчик увеличивает его. Чтобы запретить слишком много очереди в очереди, когда рабочие потоки заняты и, следовательно, занимают слишком много ресурсов, вы также можете попросить их подождать семафор «число доступных слотов очереди», который уменьшается в очереди и увеличивается с увеличением рабочего потока. Это всего лишь примеры, детали до вас. Вам также понадобится способ указать потокам прекратить ожидание работы.

1 голос
/ 02 апреля 2011

Мои 2 цента: в зависимости от количества и частоты событий, генерируемых хост-приложением, основная проблема, которую я вижу, связана с производительностью. Создание и уничтожение потока имеет стоимость [с точки зрения производительности]. Я предполагаю, что каждый порожденный поток не должен делиться каким-либо ресурсом с другими потоками, поэтому нет конкуренции. Если все потоки назначены одному ядру вашего ЦП и балансировка нагрузки отсутствует, вы можете легко перегрузить один ЦП и выгрузить другие [в многоядерной системе]. Я рассмотрю политику соответствия потоков + балансировки нагрузки.

Другая проблема может быть связана с ресурсом [read memory] Сколько памяти будет использовать каждый поток LUA?

Также будьте очень осторожны с утечками памяти в потоках LUA: если события частые, а потоки часто создаются / уничтожаются, оставляя неиспользуемую память, вы можете использовать память вашего хоста довольно скоро;)

...