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

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

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

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

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

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

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


person Kurt Schindler    schedule 27.08.2009    source источник


Ответы (4)


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

person Joel Coehoorn    schedule 27.08.2009
comment
Не забывайте значения сеанса. :) - person Randolpho; 27.08.2009
comment
В какой момент значения сеанса будут доступны более чем одному потоку? - person Ε Г И І И О; 08.10.2012

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

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

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

person Bob    schedule 27.08.2009
comment
Мне нравится, что вы указали на это - я согласен и не имел в виду, что разработчик как человек не должен изучать нюансы многопоточности. Просто я продолжаю сталкиваться с не потокобезопасным!! предупреждающие сообщения так часто, что это немного отвлекает, хотя на самом деле это может не беспокоить большинство приложений ASP.NET. - person Kurt Schindler; 27.08.2009

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

person Charles Bretana    schedule 27.08.2009

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

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

person Community    schedule 27.08.2009