Разработчики ASP.NET должны действительно быть обеспокоены потокобезопасностью?
Если Вы будете программистом Java/C#, изучающим C++, то Вы испытаете желание продолжать думать с точки зрения Java/C# и переводить дословно в синтаксис C++. В этом случае Вы только извлекаете ранее упомянутую пользу из собственного кода по сравнению с интерпретируемым/JIT. Для получения самого большого увеличения производительности в C++ по сравнению с Java/C# необходимо учиться думать в C++ и коде дизайна конкретно для использования преимуществ C++.
Для перефразирования Edsger Dijkstra : [Ваш первый язык] калечит ум вне восстановления.
Для перефразирования Jeff Atwood : можно записать [первый язык] на любом новом языке.
4 ответа
В дополнение к статическим элементам существуют определенные объекты, которые используются во всех запросах приложения. Будьте осторожны при помещении в кеш приложения элементов, например, небезопасных для потоков. Кроме того, ничто не мешает вам создавать собственные потоки для фоновой обработки при обработке запроса.
Существуют разные уровни разработчиков ASP.NET. Вы могли бы сделать прекрасную карьеру в качестве разработчика ASP.NET, ничего не зная о потоках, мьютексах, блокировках, семафорах и даже шаблонах проектирования, потому что большая часть приложений ASP.NET в основном являются приложениями CRUD с минимальной или нулевой дополнительной бизнес-логикой.
Однако большинство великих разработчиков ASP.NET, с которыми я столкнулся, не просто разработчики ASP.NET, их навыки охватывают весь спектр, поэтому они знают все о многопоточности и других хороших вещах, потому что они не ограничиваются ASP.NET.
Так что нет, по большей части ASP. Разработчикам .NET не нужно знать о безопасности потоков. Но что за удовольствие знать только самый минимум?
Только если вы создаете в потоке обработки для одного HTTPRequest несколько собственных потоков ... Например, если веб-страница будет отображать котировки акций для набора акций, и вы выполняете отдельные вызовы службы котировок акций в независимых потоках, чтобы получить котировки, прежде чем генерировать страницу для отправки обратно клиенту ... Затем вам нужно будет убедиться, что код, который вы запускаете в , ваш thread - потокобезопасный.
Я думаю, вы очень хорошо все это осветили. Я согласен. Сосредоточение внимания только на ASP.NET редко (если вообще возникает) приводит к проблемам с многопоточностью.
Однако ситуация меняется, когда дело касается оптимизации. Всякий раз, когда вы запускаете длительный запрос, вы часто можете позволить ему выполняться в отдельном потоке, чтобы загрузка страницы не останавливалась, пока сервер не сообщит о тайм-ауте соединения. Вы можете захотеть, чтобы эта страница периодически проверяла статус завершения, чтобы уведомить пользователя. Здесь речь идет о проблемах с многопоточностью.