Следует ли избегать потоков, если это вообще возможно, внутри компонентов программного обеспечения?

Question

Недавно я рассматривал код, в частности, компонентно-ориентированный код, который использует потоки внутри.Это плохая практика.Код, на который я смотрел, был из примера F #, который показал использование методов программирования на основе событий.Я не могу опубликовать код в случае нарушения авторских прав, но он раскручивает собственную ветку.Это считается плохой практикой или возможно, что не написанный вами код полностью контролирует создание потоков.Я подчеркиваю, что этот код не является визуальным компонентом и очень "построен с нуля".

Каковы лучшие практики создания компонентов, где многопоточность была бы полезна?

ЯВ этом вопросе f ​​# мог бы быть написан на c # или python.

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

Я думал о таких методах, как инъекция объектов и так далее, но потоки странные, так как они являются с точки зрения компонента чистым «действием», а не «моделью, состоянием, объявлениями»

любая помощь будет полезна.

Answer 1

Это слишком общий вопрос, чтобы иметь какой-либо ответ более конкретный, чем «это зависит»: -)

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

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

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

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

Answer 2

Нет ничего плохого в создании новых потоков в компоненте / библиотеке.Единственное, что может быть неправильным, - это если он не даст потребителю API / компонента способ синхронизации при необходимости.

Answer 3

Прежде всего, какова природа компонента, о котором вы говорите?Это DLL, чтобы быть поглощенным каким-то другим кодом?Что оно делает?Каковы бизнес-требования?Все это важно, чтобы определить, нужно ли вам беспокоиться о параллелизме.

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

В-третьих, при сравнении симметричности многопоточности в c # против f # вы должны помнить, что это очень разные звери сами по себе - f # неявно делает многопоточность более безопасной длякод, поскольку нет понятия глобальных переменных, следовательно, критический раздел в вашем коде легче игнорировать в f #, чем в c #.Это делает ваш делопер лучшим местом, потому что вам не нужно иметь дело с блоками памяти, блокировками, семафорами и т. Д.

Я бы сказал, если ваш «компонент» сильно зависит от многопоточности, вы можете рассмотреть возможность использования либоПараллельный FX в C # или даже идти с F #, так как это своего рода подходы к работе с срезами времени процессора и параллелизм более элегантным способом (IMHO).

И последнее, но не менее важное, когда вы говорите о наращивании ресурсов компьютера с помощью многопоточности в вашем компоненте - пожалуйста, помните, что потоки кодирования не обязательно оказывают большее влияние на ресурсы как таковые - вы можете так же легко сделать то же самоеповреждение одного потока, если вы не распорядитесь своими объектами (неуправляемыми) должным образом, при условии, что вы можете получить исключение OutOfMemeory быстрее, если сделаете одну и ту же ошибку в нескольких потоках…