Здравствуйте, ksandro, Вы писали:


K>>>Так что ИМХО плюсы от более быстрого создания потока по сравнению с процессом, никак не могут превесить огромное количество трудноотлавливаемых ошибок, которое мы получаем из за общего адресного пространства.

S>> Вообще то используются пулы потоков, на коих и работает асинхронность и TPL

K>Ну, вот я говорю, что для большинства задач пулы потоков вполне можно заменить на пулы процессов.
K>А ассинхронность внутри процесса вполне можно реализовывать с помощью кооперативной многозадачности, что вроде и должны помогать сделать все эти "новомодные" async await (хотя концепция корутин очень старая).

Ты так и не пояснил, чем потоки в процессах лучше множества потоков в одном процессе? Все равно нужны общие данные и их блокировка при чтении и записи.
Я еще понимаю когда нужна изолированность. То есть можно выгрузить и загрузить процеес (домен).

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

смотри WaitOneAsync
https://docs.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/interop-with-other-asynchronous-patterns-and-types

Проблемы возникают тогда, когда код изначально написанный для однопотока, начинают использовать в многопоточном коде для доступа с статическим переменным