Comments 14
Concurrency – это когда мы имеем дело со многими вещами одновременно, а Parallelism – когда делаем много вещей одновременно.
Сломал мозг в попытках понять разницу.
Водитель маршрутки, который рулит, принимает оплату, говорит по телефону и щелкает семки имеет дело со многими вещами одновременно или делает много вещей одновременно?
Количество вошедших пассажиров, отчаянно сующих деньги за проезд это concurrency, а вот количество которое водитель может одновременно обслужить — parallelism. Правда обычно он равен единице, ну или максимум двум, когда одной рукой отдает сдачу, а второй берет деньги у следующего пассажира.
Спасибо за маршрутчика, действительно все так :)
Но, вот все-таки, определение конкурентности и параллелизма, которые даются в статье, нуждаются в доработке.
Я бы так написал:
параллелизм:
в литературе: похожесть
в быту и академических кругах: одновременность
в геометрии: пересекаемость прямых
в программировании: вот тут поподробнее…
в общем-то, это слово уже вызывает некоторую путаницу. Я честно пытался гуглить, чтобы найти красивое определение в заслуживающем доверия источнике, но не нашел. Если вы сделаете тоже самое, то увидите, что найденные определения как-то подозрительно отличаются друг от друга. Не то чтобы сильно, но общее представление не складывается. Это корень проблемы, порождающей бесконечные споры и непонятки вокруг термина. Я запутаю его еще сильней :)
Для себя, я разделяю параллельность на машинную и алгоритмическую. Это мои собственные термины, так что можете не гуглить.
Машинная: одновременное выполнение блока машинных инструкций. Ну или «почти» одновременное (псевдопараллельность).
Алгоритмическая: никак не связана с инструкциями, процессорами и т.д. Мы просто выполняем несколько алгоритмов сразу. Это могут быть разные алгоритмы (параллелизм задач) или один и тот же, но с разными входными данными (параллелизм данных, SIMD)
Ключевой момент здесь — эти блоки инструкций или алгоритмы выполняются от начала до конца без остановки. В случае с «настоящим» параллелизмом, код выполняется на нескольких ядрах одновременно. В случае с псевдопараллелизмом, на одном, так что остановки есть, но они замаскированы и прозрачны для наблюдателя. В алгоритмическом случае мы вообще абстрагируемся от того, как что-то выполняется.
Конкурентность:
В бытовом и политическом плане: соперничество
В бизнесе и экономике: работы на одном рынке
В программировании: частный случай параллелизма
В машинном параллелизме рассматривается тема разделения времени выполнения потоков на доступные процессорные ядра: планировщик ОС выделает «кванты» времени каждому потоку по чуть-чуть, переключаясь между ними так, чтобы «никому не было обидно», как многодетная мать, которой важно, чтобы всем детям досталось ее внимание.
В алгоритмическом параллелизме мы по-прежнему абстрагированы от все этих процессоров. Вместо них рассматривается тема разделения каких-то общих ресурсов. В теории неважно, каких именно. На практике это могут быть файлы, открытые на запись, сетевые порты, периферийные устройства, которые не умеют работать параллельно или даже пользователь, которому надо показать несколько модальных окон или popup’ов, но не сразу.
В машинной конкурентности рассматриваются темы асинхронности и зеленых потоков.
В алгоритмической – примитивы синхронизации.
P.S. чтобы все запутать еще сильнее, можно упомянуть, что "просто" параллелизм и конкурентность не являются взаимоисключающими. Параллельно-конкурентное выполнение тоже возможно
Параллели (простите за каламбур) из других областей знания не особо полезны, я предлагаю ограничиться теорией массового обслуживания, и тут пример с маршруткой в тему.
Спасибо за статью! Очень познавательно, проделана большая аналитическая работа. Сам сталкивался с такими ситуациями не раз, были предположения, но теперь все удалось разложить по полкам.
Наглядно, полезно. Спасибо!
Аналогичную картину можно наблюдать на балансировщике, когда бэкенд завален работой и время обработки запросов уходит до таймаутов — на балансировщике наблюдается стремитпльный рост количества открытых соединений и запросов в секунду, хотя клиентов больше не стало — просто запросы приходят и копятся, т.к. ждут ответа.
Небольшое предупреждение для тех, кто думает что вся проблема из-за асинхронности, и вариант с пулом потоков этой проблеме не подвержен:
На самом деле, пул потоков в .NET может расти неограниченно, так что под нагрузкой и синхронный вариант точно так же разрастется и умрет. А ограничивать число потоков в пуле нельзя — иначе перестанут работать таймеры, что, в свою очередь, не даст вам отменить более старые задачи по тайм-ауту.
Тут спасает скорее ограничитель на входе в пайплайн ASP.NET, который не дает начинать обработку нового запроса пока потоки пула заняты — но это особенность именно что старого ASP.NET, в альтернативных фреймворках такой защиты нет. Даже в ASP.NET Core её нет! (зато там есть встроенный ограничитель числа соединений без разделения на синхронные и асинхронные)
Пул потоков с точки зрения Concurrency играет еще одну злую шутку с приложением.
Поначалу он ограничивает конкурентность, но при накоплении запросов на обработку, начинает расти по «умному» алгоритму, там даже применяется примитивный Machine Learning.
Это значит, что пул сначала защищает приложение, отчасти выполняя роль Bulkhead, но через некоторое время эта защита снимается, и это никак нельзя проконтролировать, пул разрастается непомерно. Например, за 10 минут он может вырасти до 1200 threads. Кроме проблемы Concurrency, это приводит к проблеме см. предыдущую статью День, когда Dodo IS остановилась. Синхронный сценарий
спасибо большое за статью, ещё давно её добавил себе когда не мог комментарии оставлять! вы очень помогли с пониманием этих вещей
День, когда Dodo IS остановилась. Асинхронный сценарий