#18 Многопоточность - Thread, ThreadPool, Task. Ответ на вопрос собеседования C# / .Net 

Спасибо за комментарий!

Спасибо за комментарий👍

Спасибо! В планах - создание около 35 видео на тему C#, то есть ещё около 15 видео. А потом будут видео на другие темы информатики.

@@AndreyShyrokoriadov Спасибо за работу. С нетерпением жду следующих уроков =)

@@olegholostenco8736 я стараюсь публиковать новые видео каждую субботу с утра.

А я рад подписчикам - представителям прекрасной половины человечества. Их у меня на канале около 10%.

@@AndreyShyrokoriadov очень хорошо рассказано про потоки) Теперь у меня в голове все уложилось по полочкам) На эту базу уже можно читать Рихтера. Сразу без понимая всего та, часть книги, где он пишет про потоки не зашла.

😂😂😂

Спасибо за комментарий и подписку. Если у Вас есть выбор что использовать: Thread, ThreadPool или Task, то конечно лучше использовать Task. О разнице между Thread и ThreadPool я по моему говорил в видео, а что касается ThreadPool и Task, то между ними разница следующая: при использовании Task Вы всегда знаете когда выполнение задания закончено, а при использовании ThreadPool нет встроенного способа определить закончено ли задание и какое значение было возвращено. Собственно этот недостаток ThreadPool послужил причиной появления концепции Task. В .Net есть такое понятие, как TaskScheduler - он отвечает за старт заданий и управляет заданиями в процессе их работы. TaskScheduler использует потоки из ThreadPool. То есть "под капотом" Вы и так используете ThreadPool, но теперь у Вас есть доступ к статусу задания (завершено/не завершено) и если задание завершено, то есть доступ к его результату. После того как я закончу серию видео о C# я планирую выпустить одно большее видео, которое будет называться Errata ("ошибки" на латинском языке) - в этом видео дам более детальные ответы на некоторые вопросы. Пока таких вопросов 3 (на основании комментариев зрителей) и среди них будет Ваш вопрос о том, в каких потоках выполняется Task.

Хорошо, спс, будем ждать видео

@@AndreyShyrokoriadov идея супер, такого действительно нет про разбор ошибок

@@AndreyShyrokoriadov планируете ли вы в будущем снимать уроки по обучению. Net core? Хотелось бы ещё видео о проведении ревью, рефакторинге кода, такое часто дают на собесах

@@ramil9209 видео о .net core уже есть на канале. Видео о ревью и рефакторинге - хорошая идея.

Интересное наблюдение. Вообще у меня просто тихий голос - это имеет свои преимущества и недостатки.

В этом случае я не хотел рекламировать "бренд" :) По сути это ручка с логотипом одного из моих клиентов.

Асинхронность хорошо видно в приложениях с интерфейсом пользователя. Попробуйте скачать файл или данные из веб услуги синхронно в потоке интерфейса пользователя (UI Thread). Приложение будет подвисать. Если программист оставить поток интерфейса пользователя в покое и основную работу приложения будет выполнять асинхронно в отдельных потоках, то приложение не будет подвисать. Когда асинхронная операция будет завершена, интерфейс пользователя буде обновлен. Во время выполнения асинхронной операции пользователь может спокойно взаимодействовать с интерфейсом пользователя и вызывать другие асинхронные операции, например одновременно скачивать или подгружать несколько файлов.

@@AndreyShyrokoriadov получается задача , например скачивание, или обработка, уйдет в тредпул. А пользователь будет работать с главным потоком?

@@glorglorsky7987 да, Вы правильно поняли.

Я немного прояснил ситуацию с mutex и semaphore в этом видео ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-x1ake02sgY0.html

На сколько я помню, в моих видео нет видео посвященного исключительно ключевым словам async/await

Спасибо за подписку и комментарий. Обратите внимание на это видео ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Uwo0by4OHjs.html - там есть пример использования коллекции ConcurrentQueue. Код в этом видео доступен здесь: github.com/ashyrokoriadov/TelephoneExchange

данные придут через "икс" секунд. В это время в интерфейсе пользователя будет какая то анимация символизирующая ожидание. То есть клиент ничего сразу не получит. Он получит данные, как только они будут готовы (после выполнения таска). А если таск настолько массивный, что он длится минуты или даже часы, то можно клиенту сразу вернуть статус 201 Accepted (естественно без данных). Когда таск будет выполнен об этом надо как-то проинфирмировать клиента (есть разные способы, например с помощью библиотеки SignalR). Сообщение клиенту будет содержатьинформацию о том, что такс закончился и данные можно скачать без задержек.

@@AndreyShyrokoriadov спасибо большое за разъяснения 🤝

Большое спасибо.

Спасибо за комментарий. Моё пониманием такое: количество потоков ограничено. Просто если вы берете поток через класс Thread, Вы можете попасть в ситуацию, когда доступных потоков просто не будет и в приложении появится ошибка. ThreadPool это как бы надстройка над потоками и он за нас решает проблемы связанные с использованием потоков: "выдает" нам потоки, "забирает" их обратно, когда работа в потоке выполнена. Что касается ThreadPool и Task, то между ними разница следующая: при использовании Task Вы всегда знаете когда выполнение задания закончено, а при использовании ThreadPool нет встроенного способа определить закончено ли задание и какое значение было возвращено. Собственно этот недостаток ThreadPool послужил причиной появления концепции Task. В .Net есть такое понятие, как TaskScheduler - он отвечает за старт заданий и управляет заданиями в процессе их работы. TaskScheduler использует потоки из ThreadPool. То есть "под капотом" Вы и так используете ThreadPool, но теперь у Вас есть доступ к статусу задания (завершено/не завершено) и если задание завершено, то есть доступ к его результату.

@@AndreyShyrokoriadov Спасибо за подробное разъяснение)

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PnMRa9WQkXg.html

@@AndreyShyrokoriadov спасибо

хочу вам подсказать что нужно изменить - с точки зрения начинающего программиста .. . вот вы говорите "существует 4 конструктора класса ПОТОК" . . . так вот когда вы излагаете при СИСТЕМНЫЕ конструкторы, свойства, методы, делегаты, расширения - нужно(на примере данного случая) показать на секунду вот эту страничку(тут адрес интернет-страницы Микрософта с одним из 4-х конструкторов потока) и продолжать излагать НА ПРИМЕРЕ таких или аналогичных сигнатур тогда начинающие будут знать как применить этто или подобное . . . ни у одного из блогеров этого нет(хотя некоторые периодически нажимают F12) . . . особенно это поможет когда там вообще нет примера - только сигнатура

@@user-zd3qw7le5c Хороший и полезный комментарий. Спасибо.

@@AndreyShyrokoriadov тогда будет смотреть ПОИНТЕРЕСНЕЙ - ведь такие методы изложения нигде ни раскрыты(на других ресурсах)

Конечно :)

С удовольствием посмотрел бы видео с Вашей версией объяснения этой темы, но что-то у Вас на канале пустовато... Для такого претензионального заявления. Кстати словао "чушь" пишется с мягким знаком.

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

У меня возник момент когда на одном ПК многократный вызов одного и того же Task мог выполнять их в разное время независимо друг от друга, а на другом, все Task (вызов одного и того же задания или же разные Task) встали в очередь и ожидали выполнение последовательно.

​@@SetAngelGreenсколько у вас ядер на ПК из первого и на ПК из второго случая?