Здравствуйте, Serginio1, Вы писали:

N>>2. При высокой цене переключения между нитками внутреннее переключение (шедулером на границе awaitʼа) будет в разы дешевле переключения через ОС.
S> Вот спасибо! Все таки дешевле!

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

S> Ну давай возьмем типичный сервер. БОльшая часть задач сводится к вызову асинхронным методов а именно запрос к базе данных (не локальной), запрос к сайту, к файлу итд.
S>Выделять для каждого запроса отдельный поток не имеет смысла (тут и затраты на создание потока или держать пул огромного размера).
S>Как правило эти задачи небольшие.
S> Отдельный поток стоит выделять для длительных задач LongRunning

Пока кэпствуешь, ok.

S> То есть смысла в выделении потоках на задачу нет. Есть смысл использовать пул потоков. Что было кстати в ранних версиях вэб сервисов ASP.Net.
S>Тогда тоже были и асинхронные делегаты (BeginInvoke() и EndInvoke()) и ThreadPool. Но в том же сервисе вызов вэб метода был синхронным, то есть привязан к одному потоку. То есть внутри то можно было использовать калбеки и прочее, но поток морозился на эвенте

Эти все подробности не знаю и они мне как-то побоку.

S>То есть например когда мы в базе данных что то активно меняем, и запросов на чтение как раз и будут ждать пока не закончится запись.
S>Конечно можно по максимуму съузить блокировки, но не всегда это возможно.

Так какое отношение это всё имеет, например, к качеству управления локами?