Сегодня будем разбираться с volatile и всем, что с ним связано. Тема эта интересна тем, что чтобы полностью её понимать необходимо опуститься вплоть до уровня процессора и даже узнать чем отличаются разные процессорные архитектуры в плане работы с памятью. Так как материал объёмный и сложный, то не буду пытаться, что-то объяснить сам, а буду давать ссылки.

Что о volatile нам рассказал Рихтер

У Рихтера в книге для volatile отведёно 7 страниц и этого явно недостаточно, чтобы хорошенько разобраться с темой.

Компилятор C#, JIT-компилятор и даже сам процессор могут оптимизировать ваш код. В процессе оптимизации кода компилятором C#, JIT-компилятором и процессором гарантируется сохранение его назначения. То есть с точки зрения одного потока метод делает то, зачем мы его написали, хотя способ реализации может отличаться от описанного исходном коде. Однако при переходе к многопоточной конфигурации ситуация может измениться.

То есть, если у вас многопоточное приложение с разделяемыми несколькими потоками данными (например полями класса), то у вас нет гарантии того, что данные в эти разделяемые поля будут записаны одним потоком и прочитаны другим потоком именно в том порядке, в котором вы их написали в своём коде.

Поехали

В этой статье я разбираю, как Double хранится в памяти, но это не самостоятельная статья, в том плане, что вряд ли вы сможете разобраться с этой темой, прочитав одну её, поэтому я порекомендую ссылки на другие статьи (хотя и их тоже не назовёшь идеальными).

У Джона Скита есть две коротенькие статьи на эту тему, первая: Binary floating point and .NET - про double и float, вторая: Decimal floating point in .NET - про decimal (в этой статье я не касаюсь Decimal).

Сам Скит рекомендует к прочтению эту статью: Floating Point in .NET part 1: Concepts and Formats - она более подробная и позволит более основательно разобраться в вопросе.

Также в процессе подготовки этого материала я нашёл статью на русском: Взгляд со стороны: Стандарт IEEE754 - она в целом о стандарте хранения чисел IEEE754, статья основательная, но довольно абстрактная и её не назовёшь лёгким, доступным материалом.

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

В этой статье я хотел бы разобрать вопрос управления временем жизни объектов при использовании Inversion of Control контейнера Castle Windsor.

Мы рассмотрим такие вопросы как:

• Как Castle Windsor управляет жизненным циклом создаваемых объектов.

• Можно ли вызывать Dispose() метод у полученных из контейнера объектов.

• Когда нужно вызывать _container.Release(someObjectInstance).

• Как работают различные Lifestyle’ы и Lifecycle’ы Castle Windsor.

Castle Windsor и жизненный цикл создаваемых им объектов

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

Давайте рассмотрим пример:

public class UnitOfWork
{
   public void Init()
   {
      // some initialization logic...
   }
   public void Commit()
   {
      // commit or rollback the UoW
   }
}

В этой статье я опишу новый проект веб-приложения ASP.NET 5, а также расскажу о настройке и использовании Grunt в нем.

Проект ASP.NET 5

Мы будем использовать Visual Studio 2015 Community Edition - она бесплатна для личного использования.

После ее установки и запуска, выберите “File”, “New”, “Project”, а затем в разделе “Templates”, “Visual C#”, “Web” выберите “ASP.NET Web Application”.

Последняя версия этой статьи опубликована на habrahabr.ru

Вступление от переводчика

Данная статья является переводом ASP.NET 5 - A Deep Dive into the ASP.NET 5 Runtime - введения в архитектуру DNX Runtime и построенного на нем ASP.NET 5. Так как оригинальная статья была написана в марте 2015 года, во время, когда ASP.NET 5 был еще в стадии активной разработки (примерно beta 3), многое в ней устарело. Поэтому при переводе вся информация была актуализирована до текущей версии ASP.NET 5 (RC1), также были добавлены ссылки на связанные ресурсы (в основном на docs.asp.net) и исходный код на GitHub (смотрите только в случаях, если вам интересна реализация). Приятного погружения!

.NET Runtime Environment (DNX)

ASP.NET базируется на гибком, кроссплатформенном runtime, который может работать с разными .NET CLR (.NET Core CLR, Mono CLR, .NET Framework CLR). Вы можете запустить ASP.NET 5 используя полный .NET Framework или можете запустить используя новый .NET Core (docs.asp.net: Introducing .NET Core), который позволяет вам просто копировать все необходимые библиотеки вместе с приложением в существующее окружение, без изменения чего-либо еще на вашей машине. Используя .NET Core вы также можете запустить ASP.NET 5 кроссплатформенно на Linux (docs.asp.net: Installing ASP.NET 5 On Linux) и Mac OS (docs.asp.net: Installing ASP.NET 5 On Mac OS X).

Эта статья была опубликована в корпоративном блоге Microsoft на habrahabr.ru: Ссылка.

Сегодня мы посмотрим на систему маршрутизации в ASP.NET 5.

Как была организована система маршрутизации до ASP.NET 5

Маршрутизация до ASP.NET 5 осуществлялась с помощью ASP.NET модуля UrlRoutingModule. Модуль проходил через коллекцию маршрутов (как правило объектов класса Route) хранящихся в статическом свойстве Routes класса RouteTable, выбирал маршрут, который подходил под текущий запрос и вызывал обработчик маршрута, который хранился в свойстве RouteHandler класса Route - каждый зарегистрированный маршрут мог иметь собственный обработчик. В MVC-приложении этим обработчиком был MvcRouteHandler, который брал на себя дальнейшую работу с запросом.

Маршруты в коллекцию RouteTable.Routes мы добавляли в процессе настройки приложения.

Типичный код настройки системы маршрутизации в MVC приложении:

RouteTable.Routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{id}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional });

Где MapRoute - extension-метод, объявленный в пространстве имен System.Web.Mvc, который добавлял в коллекцию маршрутов в свойстве Routes новый маршрут используя MvcRouteHandler в качестве обработчика.

В этой статье я бы хотел дать свое объяснение как работает ковариация и контрвариация в C#.

Что такое ковариация и контрвариация

Предположим у нас есть два типа - тип Animal и тип Cat и Cat наследуется от Animal - то есть мы можем Cat привести к Animal и есть третий тип, который использует типы Cat и Animal, допустим это тип Zoo. Тип Zoo является ковариантным, если мы можем Zoo<Cat> привести к Zoo<Animal> и является контрвариантным, если мы можем Zoo<Animal> привести к Zoo<Cat>. Я использовал синтаксис обобщения в примере, но вообще - это будет не обязательно обобщение - смысл в том, что один тип использует другие типы и поддерживает приведения этих типов в контексте себя.

Классическим является пример с приведением списка:

IEnumerable<string> strCollection = new List<string>() {"string"};
IEnumerable<object> objectCollection = strCollection;

string - наследуется от object и коллекцию string мы можем привести к коллекции object.

То есть, если некоторый метод, в качестве принимаемого параметра использует IEnumerable<object>, то мы можем передать в этот метод переменную с типом IEnumerable<string> и она будет приведена к нужному типу.

Смысл ковариации и контрвариации в C#

Ковариация и контрвариация в C# существует только в контексте методов. Давайте представим, что под типом Zoo из примера выше мы подразумеваем метод, а типы Cat и Animal - это типы возвращемого значения или входного параметра - то есть под Zoo<SomeType> (где SomeType - Cat или Animal) мы подразумеваем:

Информация в посте не актуальна для ASP.NET 5

Цикл жизни ASP.NET приложения - это все что происходит с ним от его старта, до его завершения.

Цикл жизни приложения начинается тогда, когда получен первый запрос любого ресурса нашего приложения и заканчивается, когда приложение выгружается из памяти.

Стадии цикла жизни приложения Asp .Net

Получен первый запрос ресурса нашего Asp .Net приложения

1. Когда получен первый запрос любого ресурса приложения, экземпляр класса ApplicationManager создает Домен приложений, для запуска нашего приложения - каждое приложение Asp .Net загружается в собственный домен приложений и работает в нем - это предоставляет необходимый уровень изоляции приложений запущенных на одном сервере.

2. В пределах этого домена приложений, создается инстанс класса HostingEnvironment, который предоставляет доступ к информации о нашем приложении, такой как имя и папка, где приложение находится.

Причиной многих заблуждений относительно того как .NET хранит объекты в памяти, является ошибочное представление, что значимые типы всегда хранятся в стеке (stack), а ссылочные в куче (heap). На самом деле ссылочные типы - всегда хранятся в куче, а вот значимые типы могут храниться как в куче, так и в стеке.

Все локальные переменные (local variables) и параметры метода хранятся в стеке. Это касается переменных и параметров и значимых (value types) и ссылочных типов (reference types). Разница между ними в том, что они хранят. Переменные и параметры значимых типов - хранят само значение переменной. А переменные и параметры ссылочных типов - хранят ссылку на объект расположенный в куче.

Теперь рассмотрим поля (fields).

Поля являются частью сложных типов, таких как классы (class) и структуры (struct). Когда память выделяется для хранения экземпляра сложного типа, она должна также включать место для хранения и полей, который этот тип содержит. Для полей значимого типа место выделяется для хранения самого его значения, а для полей ссылочного типа место выделяется для хранения ссылки на объект в куче.