Сообщение Re[8]: Зачем нам асинхронность? от 18.08.2020 8:29
Изменено 18.08.2020 10:01 Serginio1
Re[8]: Зачем нам асинхронность?
Здравствуйте, ksandro, Вы писали:
K>>>Так что ИМХО плюсы от более быстрого создания потока по сравнению с процессом, никак не могут превесить огромное количество трудноотлавливаемых ошибок, которое мы получаем из за общего адресного пространства.
S>> Вообще то используются пулы потоков, на коих и работает асинхронность и TPL
K>Ну, вот я говорю, что для большинства задач пулы потоков вполне можно заменить на пулы процессов.
K>А ассинхронность внутри процесса вполне можно реализовывать с помощью кооперативной многозадачности, что вроде и должны помогать сделать все эти "новомодные" async await (хотя концепция корутин очень старая).
Ты так и не пояснил, чем потоки в процессах лучше множества потоков в одном процессе? Все равно нужны общие данные и их блокировка при чтении и записи.
K>>>Так что ИМХО плюсы от более быстрого создания потока по сравнению с процессом, никак не могут превесить огромное количество трудноотлавливаемых ошибок, которое мы получаем из за общего адресного пространства.
S>> Вообще то используются пулы потоков, на коих и работает асинхронность и TPL
K>Ну, вот я говорю, что для большинства задач пулы потоков вполне можно заменить на пулы процессов.
K>А ассинхронность внутри процесса вполне можно реализовывать с помощью кооперативной многозадачности, что вроде и должны помогать сделать все эти "новомодные" async await (хотя концепция корутин очень старая).
Ты так и не пояснил, чем потоки в процессах лучше множества потоков в одном процессе? Все равно нужны общие данные и их блокировка при чтении и записи.
Re[8]: Зачем нам асинхронность?
Здравствуйте, 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
Проблемы возникают тогда, когда код изначально написанный для однопотока, начинают использовать в многопоточном коде для доступа с статическим переменным
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
Проблемы возникают тогда, когда код изначально написанный для однопотока, начинают использовать в многопоточном коде для доступа с статическим переменным