В чём отличие многопоточности и асинхронности в контексте .NET C#?

Question

[returnZero]

Добрый день.
Я не до конца понимаю в чём ключевое отличие асинхронности и многопоточности.
Как я понимаю многопоточность обеспечивается классом Thread(инкапсулированный поток ОС), а асинхронность - Task, Async, Await, ThreadPool. И мол вот, при использовании этих конструкций мы не блокируем вызывающий поток. Но ведь при классической многопоточности никакой поток так же не блокируется, мы просто его создаем, кормим ему задачу и всё - основной поток свободен. Тем более при асинхронности практически всегда подразумевается многопоточность - тот же ThreadPool который работает с тасками и запускает задачи в заранее заготовленных фоновых потоках. То же самое и с async/await. Можете пожалуйста помочь упорядочить всю эту информацию, заранее спасибо!

Comments

[shurshur]

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

Когда у нас много ввода-вывода и мало процессорной работы, то асинхронность может быть очень эффективна, причём за счёт синтаксических конструкций (async/await) можно писать код очень удобно, наглядно и эффективно. Но любая вычислительная задача, любой синхронный код могут привести к заметным задержкам на выполнение других задач, это недостаток.

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

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

[Griboks]

Разница только в планировщике: для потоков используется системный планировщик, для корутин - внутренний планировщик виртуальной машины в текущем потоке.

p. s.
Но это не точно. Надо бы почитать в оф. документации.

[Станислав Макаров]

Griboks вот человек и так запутался, а вы ещё корутины вспомнили)

Answer 1

[Станислав Макаров]

Асинхронность - это способ организации вычислений, когда код, вызывающий какую-либо операцию/подпрограмму /функцию, не дожидается завершения работы этой операции, а если ему интересен результат вычислений, то он получает вместо готового результата некий способ запросить результат позже, когда он будет готов (то, что называется промисом или фьючером или ещё как-то в зависимости от языка). Это по сути противоположность "обычному" синхронному вызову, когда вызывающий код останавливается и ждёт завершения функции, чтобы получить результат. Как это будет достигнуто - это уже другой вопрос, это зависит от сути операции, запускаемой асинхронно.

Но ведь при классической многопоточности никакой поток так же не блокируется

Что такое "классическая многопоточность"? Что это за термин? Что такое неклассическая многопоточность?
Если брать потоки ОС, то операционка просто передаёт управление созданному потоку в желаемую точку входа и дальше уже поток решает что и как делать. Поток может молотить вычисления 10 минут, потом записать их куда-нибудь в файл и завершиться. Никаких кормлений задачами не будет (хотя я не совсем понимаю что такое кормить задачами в вашем контексте).

Тем более при асинхронности практически всегда подразумевается многопоточность

С чего бы? Асинхронный код полезен при большом количестве операций ввода-вывода - диск, сеть и т.д. Не обязательно это должно быть что-то, вычисляющееся в отдельном потоке. Вот, почитайте хорошую статью: There is no thread.

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

Comments

[returnZero]

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

[Василий Банников]

returnZero, в твоём случае от асинхронности никакого профита не будет, тк у тебя идёт исключительно CPU-bound работа и потоки блокируются при вызове Thread.Sleep

[returnZero]

Василий Банников, Можно ли сказать что.
На практике в C# во всех асинхронных методах используется многопоточность на основе пула потоков, хотя концептуально это не обязательно, просто реализация такая.
Преимущество же над классической многопоточностью в том, что мы не беспокоимся о работе с потоками и просто кидаем задачку на выполнение, если она не выполнена то оператор await передает управление вызывающему потоку и ожидает выполнение операции своего операнда (по сути, эта операция может выполнятся в том же потоке, но на практике чаще всего она работает через таску которая запускается в потоках из пула потоков) когда асинхронная задача завершена - await пытается продолжить работать с методом в вызывающем потоке, если это невозможно, то используется тот же поток из пула потоков. Но такая модель подходит лучше всего для IO Bound задач(запросы к БД, чтения из файла, ввод-вывод итд...) а для некоторых задач которые вызывают CPU Bound - лучше использовать многопоточность?

[Василий Банников]

returnZero, на практике разница в том что io не блокирует потоки и их в принципе создаётся меньше.
+ В теории всё может вообще на одном потоке выполняться.
+ В будущем ещё зелёные потоки будут.

Такой подход позволяет экономить ресурсы (процессор и ОЗУ), повышает пропускную способность (в случае сервера - можно теми же ресурсами обрабатывать больше запросов), а иногда ещё и повышает производительность, тк реже происходит переключение контекстов

[Kano]

На ваш вопрос уже довольно развёрнуто ответили нужно только понять ответ )
Думаю для начала нужно понять что такое поток и как он работает.
Возьмём одноядерный процессор на котором ОС каким то образом "паралельно" выполняет множество процессов. Т.е. на одном ядре процессора асинхронно выполняется код из множества потоков которые создали выполняемые процессы. В данном случае для кода в потоке выполнение синхронное, а для ядра код из потока выполняется асинхронно - постоянно приходится переключать на выполнение кода из других потоков.
Хочу добавить что переключение выполнения между потоками операция довольно тяжёлая и сам поток занимает некоторое количество ресурсов (все из за универсальности решения).
Мультипоточность обычно про паралельное выполнение кода (внутри одного потока синхронное выполнение), а асинхронность про чередующееся (асинхронное).

Answer 2

[none7]

Разница в том, что многопоточность это вытесняющая многозадачность, а async это кооперативная. А блокируймость и неблокируймость это из религии JS пришло, где потоков нет вообще. У обоих подходов есть как свои плюсы, так и свои минусы.