Нужно ли разработчикам ASP.NET заботиться о безопасности потоков? - PullRequest
18 голосов
/ 27 августа 2009

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

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

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

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

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

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

Ответы [ 4 ]

8 голосов
/ 27 августа 2009

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

4 голосов
/ 27 августа 2009

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

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

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

3 голосов
/ 27 августа 2009

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

3 голосов
/ 27 августа 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...