Собственно хотел предложить для обсуждения вот эту статью, в ней автор немного со стороны веб-разработки рассматривает подходы LAMP и Windows/VM(тут берётся Java, но многое подойдёт к CLR):
многопроцессный (multi-process) и многопоточный.
За счёт уменьшения связанности компонент решение получается более масштабируемым.
З.Ы. Хотя возможно в ряде приложений такая связанность будет наоборот выгоднее.
Здравствуйте, Курилка, Вы писали:
К>За счёт уменьшения связанности компонент решение получается более масштабируемым.
Именно. А процессы при этом использовать или потоки — помоему никакой разницы. Просто при использовании потоков гораздо проще наплести зависимостей между всем подряд и потом разбираться какой поток, блокирует какой поток на каком семафоре.
Если тоже самое написать с процессами и файлами будет ещё медленне
Здравствуйте, Курилка, Вы писали:
К> вот эту статью, в ней автор немного со стороны веб-разработки рассматривает подходы LAMP и Windows/VM(тут берётся Java, но многое подойдёт к CLR): К>многопроцессный (multi-process) и многопоточный. К>За счёт уменьшения связанности компонент решение получается более масштабируемым.
У товарища в статье красной нитью проходит следующая мысль: разработка мультизадачных приложений на потоках труднее, чем соединение процессов пайпами. Это напрягает девелоперов, измученных нарзаном (типа php), требует чрезмерного напряжения умственного мозга и т.д. Мысль бесспорная, чего уж там.
Однако в любой системе с параллелизмом должен использоваться некий координационный слой, обеспечивающий совместную работу параллельных, мнэээ..., сущностей, причем не важно, в какие примитивы нижнего уровня эти сущности отображаются (в процессы, потоки, файберы, хэндлеры и пр). Координационный слой нужно либо придумывать под задачу, либо использовать чей-нибудь готовый. Межпроцессные пайпы, мониторы Java и пр. -- это не координационный слой, а примитивы, на которых его можно делать.
AL>Однако в любой системе с параллелизмом должен использоваться некий координационный слой, обеспечивающий совместную работу параллельных, мнэээ..., сущностей, причем не важно, в какие примитивы нижнего уровня эти сущности отображаются (в процессы, потоки, файберы, хэндлеры и пр). Координационный слой нужно либо придумывать под задачу, либо использовать чей-нибудь готовый. Межпроцессные пайпы, мониторы Java и пр. -- это не координационный слой, а примитивы, на которых его можно делать.
Например, в Эрланге (под параллелизм, собственно, и заточенный) используется концепт супервайзеров (здесь, начинать с overview):
A basic concept in Erlang/OTP is the supervision tree. This is a process structuring model based on the idea of workers and supervisors.
— Workers are processes which perform computations, that is, they do the actual work.
— Supervisors are processes which monitor the behaviour of workers. A supervisor can restart a worker if something goes wrong.
— The supervision tree is a hierarchical arrangement of code into supervisors and workers, making it possible to design and program fault-tolerant software.
In the figure above, square boxes represents supervisors and circles represent workers.
Здравствуйте, Risk Server, Вы писали:
RS>Здравствуйте, Курилка, Вы писали:
К>>За счёт уменьшения связанности компонент решение получается более масштабируемым. RS>Именно. А процессы при этом использовать или потоки — помоему никакой разницы. Просто при использовании потоков гораздо проще наплести зависимостей между всем подряд и потом разбираться какой поток, блокирует какой поток на каком семафоре. RS>Если тоже самое написать с процессами и файлами будет ещё медленне
Масштабируемость и скорость, вещи далеко не связанные и часто противоречат друг другу.
Как ты потоки будешь разделять между кластером из, скажем 64 машин?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Risk Server, Вы писали:
RS>>Здравствуйте, Курилка, Вы писали:
К>>>За счёт уменьшения связанности компонент решение получается более масштабируемым. RS>>Именно. А процессы при этом использовать или потоки — помоему никакой разницы. Просто при использовании потоков гораздо проще наплести зависимостей между всем подряд и потом разбираться какой поток, блокирует какой поток на каком семафоре. RS>>Если тоже самое написать с процессами и файлами будет ещё медленне
К>Масштабируемость и скорость, вещи далеко не связанные и часто противоречат друг другу. К>Как ты потоки будешь разделять между кластером из, скажем 64 машин?
Если это действительно кластер, а не ерудна, то у него должен быть свой менеджер распределения потоков по машинам, так что тут без разницы — потоки или процессы. А вот если нужно распределить по разным машинам просто в сети — тут немного тяжелее, но это обычно не нужно, а когда нужно делается пакетная обработка.
