Многопоточное и асинхронное программирование в .NET. Владимир Крамар .NET Fest 2018
Vložit
- čas přidán 7. 08. 2019
- The talk from .NET Fest conference in Kyiv, Ukraine.
Presentation: bit.ly/2DdtUwE
Fb: / dotnetfest
Website: dotnetfest.com/
Раскрывается тема проектирования и реализации многопоточных и асинхронных приложений для платформы .NET. Обсуждаются вопросы создания потоков, их дальнейшего использования и синхронизации в контексте масштабируемости и быстродействия. Рассматриваются общие ошибки и заблуждения при проектировании многопоточности, а также способы повышения производительности.
Если ты что-то не можешь обьяснить просто - ты этого не знаешь. Владимир, просто супер! Отлично поднял вопрос. Жму руку!
Very интересная information. It помогла мне a lot.
Без шуток, сделал важные заметки для себя. Спасибо за доклад.
Шикарный доклад. По существу, без воды, с глубоким пониманием как это работает, а не просто как обезьяна - "использую, сам не понимая, главное работает". Спикеру респект. И очень доступно. За счет понимания спикером всей концепции.
Понравилось, спасибо!
Докладчик очень хорош, спасибо!
сомнительно, но окэй
Ничего не понял, но очень интересно)
Спасибо
после аттентивного ревьюинга данного видео могу нотифицировать автора о комплитальном эмилиейшонге моих ушей
Пример на 44-30 не совсем понятен. Как я понимаю код преобразуется в стейт машину, в switch конструкцию в реализации на данный момент, то есть по идее итерация for доходит до await конструкции, поток отдается и возобновляет свое выполнение после того как async операция завершилась. И если так рассуждать, то никаких 20 одновременно открытых файлов не будет. Что не так?
Читаю "Владимир Крамник" Асинхронное и многопоточное...
Думаю чегоооо?????
(Люблю шахматы)
я видел пример использования async/await на конференции 2014 года в мск, в нем крайне редко использовался новый поток Оо
в основном все делалось в одном потоке
че?)
3:20 Один поток не занимает 1 мбайт. Это его виртуальное пространство в 32 разрядной сборке (4 мб в 64-разрядной). Фактически 1 более менее пустой поток в среднем занимает 8-10 страниц памяти, т.е всего около 32-36 кбайт памяти.
Речь не о потоке, а его стеке, более того сами мелкомягкие заявляют, что ARM, x86 и x64 имеют размер стека по умолчанию равный 1 МБ. Также в конце упоминается, что не всегда стек занимает 1мб.
@@rustyscarlet Да, стек, неправильно выразился. На каждый поток выделяется свой стек, размер виртуального пространства которого лимитирован определённой величиной. Напимер для 32 разрядной системы это около мегабайта по умолчанию. Но это не значит что этот мегабайт сразу алоцирован для потока. Физическая память выделяется по требованию, страницами. И в среднем, каждому потоку нужно всего несколько страниц стека. В этом можно убедится, если запустить например process hucker и посмотреть сколько страниц и памяти и физически байт, выделяется для каждого потока любого многопоточного приложения.
@@user-lt7rn4of7y память в куче выделяется последовательно, по мере необходимости, память в стеке - целиком и сразу.
Афтар по моему чето курил
44:48 что-то я не понял как там мгновенно создадутся 20 потоков к файлам. Там вроде как это будет происходить по очереди и каждая задача будет awaitиться, новая не начнется пока не закончится предыдущая итерация.
ему надо было в цикле создать асинхронные таски, а уже потом их ожидать... а вообще таски потоки не создают, а берут потоки из пула
Очень сильно режет слух мешанина из русского и английского. Да и в целом доклад какой-то скомканный...
Почему так? У нас вся литература на английском, терминология всем понятна.
@@user-zd6di5mq9z Потому что сейчас очень много материалов на русском языке с хорошим переводом в сети, а в книгах так и подавно. Хочешь читать\говорить на русском - пожалуйста. На английском - тоже никто не запрещает, если навык позволяет. Но только не оба варианта одновременно.
Я не то чтобы совсем против англицизмов - иногда очень сложно подобрать перевод к слову или выражению, потому что в русском языке аналогичного понятия нет. Но в случае наличия подходящего по значению русского слова считаю что использоваться должно именно оно, дабы не загаживать язык всяким непотребством аки "треды", "таски", "чекинить", "резолвить" и т.д.
@@user-tv5rk1fj7o , но ведь в команде разработки все говорят вот такими словами, разве нет?
@@user-tv5rk1fj7o Не забывайте, что в русском языке ещё есть правила использования знаков препинания.
@@user-tv5rk1fj7o потому, что если сравнить кол-во оригинальных материалов на англ. и то, что переведено на русский, то все самые свежие и актуальные выступления/книги/статьи и т.д. - не переведены. Переводы просто катастрофически не поспевают за всеми обновлениями и нововведениями. Как следствие, если мы в русскоязычном сообществе, то мы общаемся на русском, но как разработчики (если мы, как я считаю - хорошие разработчики), работаем с английским языком, получаем и информацию и т.д. По этому использование англицизмов в этом случае - естественная практика, наоборот, позволяющая улучшить понимание, потому что в 95% случаев ты работаешь именно с "оригинальными" названиями и определениями, а не их адаптацией под русский язык, иначе вас просто тяжело будет понять. А держать в голове по 2 определения и постоянно ментально между ними переключаться - тоже такая себе идея. Так что если вы разработчик и это вам режет слух, то что тут сказать, или терпеть, или корректировать свой профессиональный путь.