Здравствуйте, -rsdn-, Вы писали:
R>кажется я знаю 3-4: R>...
Именно способы создания потока или вообще параллельного выполнения кода? (в новом созданном потоке, в потоке, взятом из пула, Task<>, async/await, ...)
Здравствуйте, -rsdn-, Вы писали:
R>кажется я знаю 3-4: R>делегаты (асинхронный BeginInvoke и синхронный Invoke) R>Thread.Start() R>TreadPool.QueueUserWorkItem()
1. Вы путаете создание потока и отправку задания в очередь.
2. BeginInvoke это просто интерфейс (может выполнится асинхронно, а может и синхронно) — его асинхронность это ваш домысел без какой-либо гарантии.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, koodeer, Вы писали:
K>>Под вопросом: Task.Run, Task.Factory.StartNew.
_>Эти берут потоки из пула. Под вопросом что-то иное?
С опцией TaskCreationOptions.LongRunning будет создаваться новый поток.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, -rsdn-, Вы писали:
R>>кажется я знаю 3-4: R>>делегаты (асинхронный BeginInvoke и синхронный Invoke) R>>Thread.Start() R>>TreadPool.QueueUserWorkItem()
TK>1. Вы путаете создание потока и отправку задания в очередь. TK>2. BeginInvoke это просто интерфейс (может выполнится асинхронно, а может и синхронно) — его асинхронность это ваш домысел без какой-либо гарантии.
соглашусь, я ведь писал 3-4 , т к не уверен можно ли разделить sync/async
Здравствуйте, andrey82, Вы писали:
A>Здравствуйте, -rsdn-, Вы писали:
R>>кажется я знаю 3-4: R>>...
A>Именно способы создания потока или вообще параллельного выполнения кода? (в новом созданном потоке, в потоке, взятом из пула, Task<>, async/await, ...)
я всего лишь попросил вопросы к собеседованию = что дали с тем и разбираюсь, больше чем в топике сказать не могу
Здравствуйте, -rsdn-, Вы писали:
R>кажется я знаю 3-4:
Их всего два. Или вручную — ч/з Thread
Или неявно — 'это к ThreadPool.
Для неявного есть куча частных случаев — таски, Delegate.BeginInvoke(), completion callbacks для io-операций (от таймеров и до веб-запросов), Rx, операции с SyncContext и прочая. Причём для половины из этих способов есть шанс, что код по факту новый поток (Thread) создан не будет.
Хочется экзотики — велкам в AsyncCodeActivity в WF, wcf concurrency, хаки с wpf render thread, finalizer thread, MTA COM + native thread, appdomain unload, [DebuggerDisplay] для выполнения в потоке отладчика etc etc etc.
Здравствуйте, -rsdn-, Вы писали:
R>кажется я знаю 3-4: R>делегаты (асинхронный BeginInvoke и синхронный Invoke) R>Thread.Start() R>TreadPool.QueueUserWorkItem()
Не с собеседования ли вопрос?
Многие интервьюеры по наивности задают подобный вопрос именно в такой формулировке. Но, как правильно написали выше, она не корректно звучит, ведь по сути, если не уточнять, что такое "поток", то ответить на этот вопрос вообще нельзя. Если же уточнить (что это поток ОС-ки или CLR), то мы скатимся к тому, что останется лишь один вариант ответа.
Именно поэтому, корректный вопрос должен звучать так:
Сколько вы знаете способов выполнить некоторую операцию (представленную, например, методом) асинхронно.
И тут поехали уже вариации на тему:
— Создать поток вручную
— Использовать классический пул потоков с помощью ThreadPool.QueueUserWorkItem
— Таски: Task.Run, Task.Factory.StartNew (с вариациями на тему LongRunning или нет).
— Delegate.BeginInvoke
— BackgroundWorker
Но, по сути, ответ на вопрос сводится к тому, что мы можем создать поток вручную или воспользоваться некоторой дополнительной абстракцией, которая будет отвечать за более эффективное использование потоков. При этом абстракция может быть прибита к среде исполнения, как в случае со стандартным пулом потоков (и ее тюнингованной версией для работы с тасками), на уровне стандартной библиотеки (Delegate.BeginInvoke) или на уровне FCL (BackgroundWoker, который уже использовать смысла-то нет).
Обычно после этого должен следовать еще и такой вопрос: А когда чем лучше пользоваться? Когда есть смысл создавать поток вручную, а когда с использовать пул потоков. Или еще более тонкий: а в чем разница между ThreadPool.QueueUserWorkItem и Task.Run (при учете, что таска не LongRunning)?.
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, -rsdn-, Вы писали:
R>>кажется я знаю 3-4: R>>делегаты (асинхронный BeginInvoke и синхронный Invoke) R>>Thread.Start() R>>TreadPool.QueueUserWorkItem()
ST>Не с собеседования ли вопрос?
ST>Многие интервьюеры по наивности задают подобный вопрос именно в такой формулировке. Но, как правильно написали выше, она не корректно звучит, ведь по сути, если не уточнять, что такое "поток", то ответить на этот вопрос вообще нельзя. Если же уточнить (что это поток ОС-ки или CLR), то мы скатимся к тому, что останется лишь один вариант ответа.
ST>Именно поэтому, корректный вопрос должен звучать так: ST>Сколько вы знаете способов выполнить некоторую операцию (представленную, например, методом) асинхронно.
ST>И тут поехали уже вариации на тему:
ST>- Создать поток вручную ST>- Использовать классический пул потоков с помощью ThreadPool.QueueUserWorkItem ST>- Таски: Task.Run, Task.Factory.StartNew (с вариациями на тему LongRunning или нет). ST>- Delegate.BeginInvoke ST>- BackgroundWorker
ST>Но, по сути, ответ на вопрос сводится к тому, что мы можем создать поток вручную или воспользоваться некоторой дополнительной абстракцией, которая будет отвечать за более эффективное использование потоков. При этом абстракция может быть прибита к среде исполнения, как в случае со стандартным пулом потоков (и ее тюнингованной версией для работы с тасками), на уровне стандартной библиотеки (Delegate.BeginInvoke) или на уровне FCL (BackgroundWoker, который уже использовать смысла-то нет).
ST>Обычно после этого должен следовать еще и такой вопрос: А когда чем лучше пользоваться? Когда есть смысл создавать поток вручную, а когда с использовать пул потоков. Или еще более тонкий: а в чем разница между ThreadPool.QueueUserWorkItem и Task.Run (при учете, что таска не LongRunning)?.
Да с собеседования.
плохо помню, но мне сказали как-то что Thread желательно не использовать, ThreadPool лучше, но там у всех приоритет background, Task — вообще тема — т. к. там есть событие завершения (и свойство состояния). BackgroundWorker вообще не помню, Delegate — там же есть и Multicast но он же по сути и самый нужный. Вот такое смутное представление у меня.
Здравствуйте, SergeyT., Вы писали:
ST> Или еще более тонкий: а в чем разница между ThreadPool.QueueUserWorkItem и Task.Run (при учете, что таска не LongRunning)?.
С учётом вот этого — оччень тонко
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, koodeer, Вы писали:
K>>Под вопросом: Task.Run, Task.Factory.StartNew.
_>Эти берут потоки из пула. Под вопросом что-то иное?
Написав "под вопросом" я имел в виду, что Task.Run запускает всё-таки задачу, а не поток. В текущей реализации Task реализован поверх Thread. Однако, где-то в документации упомянуто, что на это нельзя закладываться, потому что в будущих версиях дотнета это может быть изменено. Например, введут зелёные потоки и Task'и могут быть сделаны поверх них.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, -rsdn-, Вы писали:
R>>кажется я знаю 3-4:
S>Их всего два. Или вручную — ч/з Thread S>Или неявно — 'это к ThreadPool.
S>Для неявного есть куча частных случаев — таски, Delegate.BeginInvoke(), completion callbacks для io-операций (от таймеров и до веб-запросов), Rx, операции с SyncContext и прочая. Причём для половины из этих способов есть шанс, что код по факту новый поток (Thread) создан не будет.
S>Хочется экзотики — велкам в AsyncCodeActivity в WF, wcf concurrency, хаки с wpf render thread, finalizer thread, MTA COM + native thread, appdomain unload, [DebuggerDisplay] для выполнения в потоке отладчика etc etc etc.
Здравствуйте, Serginio1, Вы писали:
S> Кстати а где используется функционал файберов?
Fibers как часть системного API не взлетели по куче причин. Основная: во всех нормальных фреймворках уже есть (хотя бы как proof of concept) примерно аналогичная реализация поверх пула системных потоков. Что важно — кроссплатформенная. Что ещё более важно — заточенная под нюансы языка/фреймворка.
S> Понятно, что многие вкусности файберов отняли реализация yield
Может, речь про await + TPL?
yield (если мы про шарповский) к зелёным потокам имеет такое же отношение, как картошка к апельсинам. Т.е. есть блюда, где они вместе встречаются, но это из разряда экзотики.
Здравствуйте, Sinix, Вы писали:
S>> Понятно, что многие вкусности файберов отняли реализация yield S>Может, речь про await + TPL?
S>yield (если мы про шарповский) к зелёным потокам имеет такое же отношение, как картошка к апельсинам. Т.е. есть блюда, где они вместе встречаются, но это из разряда экзотики.
Я к тому, что файберы было удобно для выполнения рекурсивного кода с остановкой для получения данных Implementing Coroutines for .NET by Wrapping the Unmanaged Fiber API
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Я к тому, что файберы было удобно для выполнения рекурсивного кода с остановкой для получения данных.
Вы только что описали await
Для полной красоты нужна поддержка языком IAsyncEnumerable или Rx, но это уже мелочи. Всяко проще, чем протащить концепцию фиберов в CLI VES.
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, Vladek, Вы писали:
V>>Где скажет планировщик (TaskScheduler), там и берут.
_>Случайный образом? Предвидеть никак нельзя?
Можно, ты же можешь поменять планировщик или вообще написать своего. Планировщик по умолчанию работает с пулом потоков.
