Многопоточная диспетчеризация событий

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

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


person Robert M    schedule 02.04.2011    source источник
comment
Какие события? Сервер, графический интерфейс или управление в реальном времени?   -  person Potatoswatter    schedule 02.04.2011
comment
Насколько надежным должно быть ваше приложение по сравнению с этими надстройками?   -  person Emil Sit    schedule 02.04.2011
comment
Хост — это клиент, подключенный к серверу. Сервер отправляет события клиенту, а клиент, в свою очередь, отправляет события надстройкам.   -  person Robert M    schedule 02.04.2011
comment
Хост должен быть надежным только до такой степени, что надстройка не будет блокировать пользовательский интерфейс или любую внутреннюю обработку хоста. Предложение использовать один поток диспетчеризации событий может работать лучше, чем мое текущее намерение.   -  person Robert M    schedule 02.04.2011


Ответы (3)


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

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

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

person Jon    schedule 02.04.2011
comment
Возможно, я не ясно выразился, но потоки будут создаваться только в момент отправки событий. Как отмечалось в других ответах, это может ухудшить системные ресурсы, в отличие от вашего предложения использовать один поток для диспетчеризации. - person Robert M; 02.04.2011

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

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

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

person asveikau    schedule 02.04.2011

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

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

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

person sergico    schedule 02.04.2011
comment
Хорошая точка зрения. Первоначально я думал об этом как о веб-сервере, создающем потоки для входящих клиентских подключений, но это может быть не так похоже, как я сначала подумал. - person Robert M; 02.04.2011