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

S>Проверил. 1000 блокированных потоков отжирают около +25 МБ ОЗУ.

Дело не в ОЗУ, дело в производительности и масштабируемости.

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

GZ>Значение зависит от состояния виртуальной памяти и количества ядер.

А можно про это подробнее?

GZ>Основная проблема открытия потока — это то что он минимум занимает виртуальную память под стек(насколько я помню — 2 мега).

1мб по умолчанию.

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

GZ>>Значение зависит от состояния виртуальной памяти и количества ядер.
S>А можно про это подробнее?
Подробнее — сам не вкурсах. Раньше было детерменированное количество потоков по умолчанию, которое зависило от количество процессоров. Теперь они зацепили состояние виртуальной памяти, что и как не в курсах. В документации было только это.

GZ>>Основная проблема открытия потока — это то что он минимум занимает виртуальную память под стек(насколько я помню — 2 мега).
S>1мб по умолчанию.
Ага. Посмотрел — именно так. Не знаю откуда взял 2 метра.

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

GZ>Подробнее — сам не вкурсах. Раньше было детерменированное количество потоков по умолчанию, которое зависило от количество процессоров. Теперь они зацепили состояние виртуальной памяти, что и как не в курсах. В документации было только это.

А можно ссыль на доку?

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

GZ>>Подробнее — сам не вкурсах. Раньше было детерменированное количество потоков по умолчанию, которое зависило от количество процессоров. Теперь они зацепили состояние виртуальной памяти, что и как не в курсах. В документации было только это.

S>А можно ссыль на доку?
Нашел.

Maximum number of thread pool threads
The number of operations that can be queued to the thread pool is limited only by available memory. However, the thread pool limits the number of threads that can be active in the process simultaneously. If all thread pool threads are busy, additional work items are queued until threads to execute them become available. Beginning with the .NET Framework 4, the default size of the thread pool for a process depends on several factors, such as the size of the virtual address space. A process can call the ThreadPool.GetMaxThreads method to determine the number of threads.

You can control the maximum number of threads by using the ThreadPool.GetMaxThreads and ThreadPool.SetMaxThreads methods.

Note

Code that hosts the common language runtime can set the size using the ICorThreadpool::CorSetMaxThreads method.

Thread pool minimums
The thread pool provides new worker threads or I/O completion threads on demand until it reaches a specified minimum for each category. You can use the ThreadPool.GetMinThreads method to obtain these minimum values.

Note

When demand is low, the actual number of thread pool threads can fall below the minimum values.

When a minimum is reached, the thread pool can create additional threads or wait until some tasks complete. Beginning with the .NET Framework 4, the thread pool creates and destroys worker threads in order to optimize throughput, which is defined as the number of tasks that complete per unit of time. Too few threads might not make optimal use of available resources, whereas too many threads could increase resource contention.

Caution

You can use the ThreadPool.SetMinThreads method to increase the minimum number of idle threads. However, unnecessarily increasing these values can cause performance problems. If too many tasks start at the same time, all of them might appear to be slow. In most cases the thread pool will perform better with its own algorithm for allocating threads.

https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.threadpool.getavailablethreads?view=netframework-4.8

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

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

GZ>В тяжелых многопоточных задачах необходимо контролировать нагрузку самостоятельно.

Или просто не блокировать надолго workitem threads.

Здравствуйте, Ночной Смотрящий, Вы писали:

GZ>>В тяжелых многопоточных задачах необходимо контролировать нагрузку самостоятельно.
НС>Или просто не блокировать надолго workitem threads.
Это индивидуально. Всегда решается компромис между производительностью и эффективностью системы и сложностью реализации, а следовательно багоемкости решения. Например, для меня очень часто важнее чистота стека, поэтому у меня мало серверного кода с await функциями. Если бутылочным горлышком является, например, БД или чужой сервис, то я бессовестно блокирую ими, потому что у них есть свои системы управлением нагрузкой, проц в этот момент не юзается, а память не жалко. Если бутылка — в процессоре, то кастомный шедулер с очередью. Я помню только одно мое приложение которое отдавало потоки в пул, и то — это была реализация IHttpAsyncHandler.

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

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

GZ>>>Подробнее — сам не вкурсах. Раньше было детерменированное количество потоков по умолчанию, которое зависило от количество процессоров. Теперь они зацепили состояние виртуальной памяти, что и как не в курсах. В документации было только это.

Сейчас в NetCore оно вообще зависит от платформы (Win/Linux), битности (32/64), процессора (ARM/x86) и кто знает чего ещё. Т.е. можно (и нужно) думать про это как implementation details.

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

GZ>Это индивидуально. Всегда решается компромис между производительностью и эффективностью системы и сложностью реализации, а следовательно багоемкости решения. Например, для меня очень часто важнее чистота стека, поэтому у меня мало серверного кода с await функциями.

Stacktrace при исключении или при отладке? Что там такого грязного?

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

GZ>>Это индивидуально. Всегда решается компромис между производительностью и эффективностью системы и сложностью реализации, а следовательно багоемкости решения. Например, для меня очень часто важнее чистота стека, поэтому у меня мало серверного кода с await функциями.

S>Stacktrace при исключении или при отладке? Что там такого грязного?
Специфика — что системы удаленные, и приходится очень щепетильно подходить к логам. Кроме восстановления самого порядка вызовов, нам очень важно иметь свой ManagedThreadId на каждый сценарий. Тогда проще восстановить как стек, так и порядок вызовов функций.

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

S>>Stacktrace при исключении или при отладке? Что там такого грязного?
GZ>Специфика — что системы удаленные, и приходится очень щепетильно подходить к логам. Кроме восстановления самого порядка вызовов, нам очень важно иметь свой ManagedThreadId на каждый сценарий. Тогда проще восстановить как стек, так и порядок вызовов функций.

async\await не ломает порядок вызов, а если есть привязка к ManagedThreadId ну тогда ладно.

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

S>>Stacktrace при исключении или при отладке? Что там такого грязного?
GZ>Специфика — что системы удаленные, и приходится очень щепетильно подходить к логам.

Ben.Demystifier не спасает?

GZ> Кроме восстановления самого порядка вызовов, нам очень важно иметь свой ManagedThreadId на каждый сценарий.

И в чем проблема? AsyncLocal вроде никто не отменял.

GZ> Тогда проще восстановить как стек, так и порядок вызовов функций.

И ради этого делать блокирующие вызовы?

Здравствуйте, Ночной Смотрящий, Вы писали:

GZ>>Специфика — что системы удаленные, и приходится очень щепетильно подходить к логам.
НС>Ben.Demystifier не спасает?
У меня свой инструментарий.

GZ>> Кроме восстановления самого порядка вызовов, нам очень важно иметь свой ManagedThreadId на каждый сценарий.
НС>И в чем проблема? AsyncLocal вроде никто не отменял.
Это достаточно новая фича.

GZ>> Тогда проще восстановить как стек, так и порядок вызовов функций.
НС>И ради этого делать блокирующие вызовы?
Для начала необходимо сказать зачем нужны неблокирующие вызовы. Вот кроме синтаксического сахара для визуального потока — придумать не могу. Когда он только появился, мы один из продуктов делали на Windows RT(еще на этапе Metro). Там ничего кроме async/await не было. На всех уровнях, вплоть до БД. И тут надо интегрировать библиотеку, которая генерит визуалку, и которая использует внутрях GDI+, а следовательно все вызовы должны быть в одном потоке. Радостей было, танцев с бубном, позвякивания колокольчиками учитывая что примитивов синхронизации практически нет(семафор и всё). Много удовольствия. Поэтому — как синтаксический сахар для визуалки, в том числе уровня UWP — на здоровье. Если серверный код — то спасибо, не стоит повышать сложность, ее и так хватает.

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

GZ>Для начала необходимо сказать зачем нужны неблокирующие вызовы. Вот кроме синтаксического сахара для визуального потока — придумать не могу.

Однако.

GZ> Когда он только появился, мы один из продуктов делали на Windows RT(еще на этапе Metro).

А, десктоп. Ну тогда понятно.