Последний раз. Ожидается ли работа с потоками?

Question

Последний раз. Ожидается ли работа с потоками?

1

Я видел некоторые подобные вопросы раньше, просто хочу прояснить это.

В этой статье говорится, что для асинхронных вызовов нет потока.

Однако, в другом, говорится

Здесь, однако, выполнялся обратный вызов, чтобы обновить текст textBox1on в произвольном потоке, где реализована реализация ContinueWith параллельной библиотеки задач (TPL).

Кроме того, в некоторых случаях, когда я вызывал ContinueWith в моем проекте, я также получил исключение доступа к перекрестным потокам.

Итак, кто прав?

ОТВЕТ: благодаря i3arnon. После прочтения первой статьи более тщательно, я нашел это место

Итак, мы видим, что в то время как запрос находился в полете, не было ни одной нити. Когда запрос был завершен, различные потоки были "заимствованы" или работа была ненадолго поставлена в очередь. Эта работа обычно составляет порядка миллисекунды или около того (например, APC, запущенная в пуле потоков) вплоть до микросекунды или около того (например, ISR). Но нет нити, которая была заблокирована, просто ожидая завершения этого запроса.

Vitalii Vasylenko 26 май 2014, в 15:25

Источник

Теги:

c#

async-await

asynchronous

task

synchronization

1 ответ

Ещё вопросы

i3arnon · Accepted Answer · 2014-05-26T11-15-00.000Z

Оба. Когда на вашем процессоре работает код, всегда работает поток. Вопрос в том, что происходит, когда у вас нет кода для запуска, например, когда вы ожидаете завершения операции ввода-вывода.

Если вы используете async await когда не будет потока, ожидающего завершения этой операции, и только после того, как он завершит поток, будет предоставлен (обычно Thread Pool), чтобы продолжить запуск кода на вашем CPU.

Если вы не используете async-await (или другую асинхронную парадигму, такую как Begin-End), вы будете держать поток на протяжении всей операции, даже в части IO, что является пустой тратой ресурсов.

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

Но .. я думал, что по умолчанию await не использует потоки, и это полезно для IO. И если у меня есть некоторые вычисления, которые я должен сделать, я использую await Task.Run() для асинхронных вычислений в другом потоке.
@VitaliiVasylenko ждать себя не так много. Он только регистрирует следующие строки кода как продолжение. Это означает, что вы не используете поток, пока ожидаете, но он вам нужен после того, как вы завершите ожидание выполнения остальной части кода.
@VitaliiVasylenko Tash.Run запустит связанную с процессором операцию, которая сама удержит поток. Но ждать его не буду. Это то, о чем я говорил в моей последней части об асинхронных операциях с привязкой к процессору.
Но в какой момент возникает проблема с потоком (если не говорить о Task.Run ()) с await? У меня есть ожидание, он помечает некоторые файлы для чтения (на низком уровне), затем они сигнализируют, что чтение завершено, и Task возвращает результат. Если нет ничего общего с потоками (как сказано в первой статье), в какое время на сцену прыгает какой-то другой поток (как сказано во второй статье)?
@VitaliiVasylenko между получением сигнала о том , что операция ввода - вывода делается и маркировки соответствующей задачи завершенным с результатом есть некоторый код. Может быть, не так много, но вам нужен какой-то поток, чтобы запустить его.
@VitaliiVasylenko Вот конкретная часть, описывающая это в блоге Стивена: «Задача захватила контекст пользовательского интерфейса, поэтому она не возобновляет асинхронный метод непосредственно в потоке пула потоков. Вместо этого он помещает продолжение этого метода в контекст пользовательского интерфейса, и поток пользовательского интерфейса возобновит выполнение этого метода, когда доберется до него ».
Спасибо за тонну, теперь я получил я.
@VitaliiVasylenko Конечно. В любой момент.