Поправьте меня, если я неправильно понимаю ваш вопрос, но я понимаю, что когда пользователи делают вызов в вопросе, речь идет о каком-то потенциально длительном вводе/выводе.
Нитки не хороший выбор, если все, что вы делаете, ждет какого-то результата. Создание дополнительных потоков в основном хорош для работы с ЦП, но преимущество их использования - много менее понятно, если все, что вы делаете, ждет чего-то.
Вам действительно нужно заменить его каким-то асинхронным или неблокирующим вводом/выводом.
Моя стандартная иллюстрация этого факта заключается в следующем: предположим, вы идете в ресторан на 10 человек. Когда приходит официант, первый человек, которого он просит, не готов; однако остальные 9 человек. Таким образом, официант просит остальных 9 человек по их приказу, а затем возвращается к оригинальному парню, надеясь, что он будет готов к заказу к тому времени. (Это определенно не так, что у них будет второй официант, ожидающий, когда оригинальный парень будет готов к заказу, и это, вероятно, не сэкономит много времени). Так во многих случаях работает async/await (исключение состоит в том, что некоторые из вызовов библиотеки задач Parallel, например Thread.Run (...), фактически выполняются на других потоках - на нашей иллюстрации, в результате чего появляется второй официант, поэтому убедитесь, что вы проверяете документацию, для которой есть).
В случае, если вы хотите, чтобы несколько официантов были предназначены для задач, которые действительно «официанты» (т. Е. Где официант будет основным удержанием для задачи). Например, если в вашем ресторане 100 столов, было бы неловко, если бы один официант попытался обслуживать всех из них, и не было бы разумно также, чтобы официант также готовил еду, как только он принимает заказы. В этих случаях вы хотите иметь отдельного человека для приготовления пищи и нескольких официантов. В конце концов вам может понадобиться несколько поваров и, возможно, busboys и т. Д. Это случай, когда у вас будет несколько потоков; в общем случае потоки будут обслуживать специализированные роли (например, официанты, буксиры, повара и т. д.) и будут «делить» работу, которая вписывается в их конкретную категорию (например, каждый официант будет работать с несколькими таблицами).
Для вашего конкретного применения, хотя, даже если вы сделать создать новый поток для обработки каждого пользователя, есть много лучших способов делать то, что вы хотите, чем непрерывно опрос для результата с использованием while и Thread.Sleep, такие как класс ManualResetEvent, который позволяет блокировать поток (или группу потоков) до тех пор, пока не произойдет какое-либо конкретное событие (таким образом, исключая необходимость в петле опроса).
Объекты, связанные с Winforms, на веб-сайте? Один поток для каждого пользователя? Занятые петли с Thread.Sleep? Что именно вы пытаетесь сделать, и почему вы считаете, что многопоточность является хорошим решением? – Luaan
Если все, что вы делаете, ждет результатов от своего рода ввода-вывода, вы не хотите создавать отдельные потоки для этого, так как инфраструктура .NET уже имеет множество механизмов для неблокирующего ввода-вывода. – EJoshuaS
Спасибо, нам нужны потоки, потому что мы поставили много лет в winforms, и много кода находится в коде (нет api), поэтому нам нужно запустить экземпляр основной формы для каждого пользователя и сохранить это в памяти во время посещения пользователем сайт. Пользовательский интерфейс html довольно глупый и просто реагирует на сигналы, предоставляемые нашим сокетом (например, открытие сообщений или небольших форм). Например, для сообщения (да/нет) сервер должен ждать выбора – flieks