Подтвердить что ты не робот

Должны ли разработчики ASP.NET действительно заботиться о безопасности потоков?

Я считаю себя осведомленным о понятиях потоковой передачи и почему определенный код является или не является "потокобезопасным", но как человек, который в первую очередь работает с ASP.NET, потоки и безопасность потоков - это то, о чем я редко думаю. Тем не менее, я, кажется, сталкиваюсь с многочисленными комментариями и ответами (не обязательно для ASP.NET) на Qaru в ответ на " предупреждение - это не потокобезопасно!", и это, как правило, делает меня второе предположение, написал ли Ive аналогичный код, который действительно может вызвать проблему в моих приложениях. [шок, ужас и т.д.] Поэтому я вынужден спросить:

Должны ли разработчики ASP.NET действительно заботиться о безопасности потоков?

My Take: Хотя веб-приложение по своей сути многопоточно, каждый конкретный запрос входит в один поток, и все нестатические типы, которые вы создаете, изменяете или уничтожаете, являются исключительными для этого единственного потока/запроса. Если запрос создает экземпляр объекта DAL, который создает экземпляр бизнес-объекта, и Я хочу ленить-инициализировать коллекцию в этом объекте, не имеет значения, не потокобезопасным, потому что он никогда не будет тронут другим потоком....Правильно? (Предположим, что Im не запускает новый поток, чтобы начать длительный асинхронный процесс во время запроса. Мне хорошо известно, что все меняется.)

Конечно, статические классы, методы и переменные просто противоположны. Они разделяются по каждому запросу, и разработчик должен быть очень осторожным, чтобы не иметь "небезопасный" код, который при выполнении одним пользователем может иметь непреднамеренный эффект для всех остальных.

Но об этом, и, следовательно, безопасность потоков в ASP.NET в основном сводится к следующему: будьте осторожны, как вы разрабатываете и используете статику. Кроме этого, вам не нужно об этом беспокоиться.

Я не прав по поводу этого? Вы не согласны? Просветите меня!

4b9b3361

Ответ 1

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

Ответ 2

Существуют разные уровни разработчиков ASP.NET. Вы могли бы сделать отличную карьеру в качестве разработчика ASP.NET, не зная ни каких потоков, мьютексов, блокировок, семафоров и даже шаблонов проектирования, потому что высокий процент приложений ASP.NET - это в основном приложения CRUD с практически отсутствующей дополнительной бизнес-логикой.

Однако большинство разработчиков ASP.NET, с которыми я столкнулся, - это не просто разработчики ASP.NET, их навыки управляют гаммой, поэтому они знают все о потоковом и других хороших вещах, потому что они не ограничивают себя ASP. СЕТЬ.

Так что нет, по большей части разработчикам ASP.NET не нужно знать о безопасности потоков. Но какая радость здесь, только зная минимальный минимум?

Ответ 3

Я считаю, что вы все это очень хорошо справились. Я с тобой согласен. Ориентируясь только на ASP.NET, он редко (если вообще) приходит к многопоточным проблемам.

Однако ситуация меняется, когда дело доходит до оптимизации. Всякий раз, когда вы начинаете долговременный запрос, вы часто можете позволить ему работать в отдельном потоке, чтобы загрузка страницы не останавливалась, пока сервер не сообщит о времени ожидания соединения. Возможно, вы захотите, чтобы эта страница периодически проверяла статус завершения, чтобы уведомить пользователя. Здесь, где речь идет о многопоточных проблемах.

Ответ 4

Только если вы создаете в потоке обработки для одного HTTPRequest несколько собственных потоков... Например, если на веб-странице будут отображаться котировки акций для набора акций, и вы делаете отдельные звонки на акции котировки на независимых потоках, чтобы получить кавычки, прежде чем генерировать страницу для отправки обратно клиенту... Тогда вам нужно убедиться, что код, который вы используете в ваших потоках, является потокобезопасным.