В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы
Проект SmartThreadPool, о котором идёт речь в статье:
⚠️ Материал средней сложности
С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работыЧитать полностью »
Скажу сразу: я никогда не жду развёрнутого ответа на этот вопрос на собесах. Это глупо и в моем случае — эгоистично. Однако, на мой взгляд, помимо общего интереса к платформе, знать, как он работает очень полезно, т.к. это снимает целый ряд вопросов. Например, исключает вариант, когда разработчик считает, что Dispose вызывается автоматически и вызывать его самому не надо. Или же если разработчик более опытен, помогает ему автоматически, на уровне мышечной памяти писать код, приводящий к наименьшему количеству проблем.
Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.
Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.
Спор взаимовыгоден: если будет не понятно, я подправлю не ясные моменты в книге, маленькой частью которой является данный текст.
Мир несется вперед, движимый прогрессом и конкуренцией. Нам с вами нереально повезло: ведь для нас работают величайшие умы, создавая поистине серъезные механизмы: компиляторы, IDE, базы данных. Делают их так, что мы получаем истинное удовольствие, используя их.
Один из этих механизмов — это работа подсистемы управления памятью платформы .NET. И если раньше никто не имел ни малейшего понятия как оно работает, то теперь, когда у нас есть исходники, все секреты открыты. Теперь видно абсолютно все подробности работы ядра платформы: и это действительно завораживает. Например, если ранее мы думали, что выделение памяти — это просто сдвинуть указатель, то теперь стало ясно что все несколько сложнее и интереснее. Это выверенный, прекрасный алгоритм, не оставляющий вопросов: а почему сделано именно так.
Второй очень важный момент — полное отсутствие времени между работой и семьей чтобы всё выучить и понять: разобраться с аспектами работы ядра платформы. Так вот данный семинар — прекрасная возможность не тратя десятки часов на вычитку блогов и книг раз и навсегда разобраться, как же всё работает. И поверьте, я очень постараюсь чтобы каждый момент был ясен всем
CLRium #5: Garbage Collector пройдет 13 апреля в Санкт-Петербурге и 20 апреля — в Москве, а все подробности — под катомЧитать полностью »
13 апреля в Санкт-Петербурге и 20 апреля в Москве будет проведен семинар CLRium #5, целиком и полностью посвященный подсистемам ядра CoreCLR и .NET Framework.
Это тот редкий случай, когда знания без всякой воды будут вливаться вам в голову на протяжении всего дня. Когда вы на собесах станете знать гораздо больше собеседующих. Ведь эта информация раскидана по всему интернету, а рассказана будет лишь единожды.
10 докладов. Исключительно про ядро. 6 из них — только про подсистему управления памятью.
It seems we came through hell and high water and can nail any interview, even the one for .NET CLR team. However, let's not rush to microsoft.com and search for vacancies. Now, we need to understand how value types inherit an object if they contain neither a reference to SyncBlockIndex, not a pointer to a virtual methods table. This will completely explain our system of types and all pieces of a puzzle will find their places. However, we will need more than one sentence.
Now, let's remember again how value types are allocated in memory. They get the place in memory right where they are. Reference types get allocation on the heap of small and large objects. They always give a reference to the place on the heap where the object is. Each value type has such methods as ToString, Equals and GetHashCode. They are virtual and overridable, but don’t allow to inherit a value type by overriding methods. If value types used overridable methods, they would need a virtual methods table to route calls. This would lead to the problems of passing structures to unmanaged world: extra fields would go there. As a result, there are descriptions of value type methods somewhere, but you cannot access them directly via a virtual methods table.
This may bring the idea that the lack of inheritance is artificial
This chapter was translated from Russian jointly by author and by professional translators. You can help us with translation from Russian or English into any other language, primarily into Chinese or German.
Also, if you want thank us, the best way you can do that is to give us a star on github or to fork repository
github/sidristij/dotnetbook.
![[DotNetBook] Время занимательных историй: исключительно исключительные ситуации - 1](https://www.pvsm.ru/images/2018/08/20/DotNetBook-vremya-zanimatelnyh-istorii-isklyuchitelno-isklyuchitelnye-situacii.jpeg "[DotNetBook] Время занимательных историй: исключительно исключительные ситуации - 1")
Существует ряд исключительных ситуаций, которые скажем так… Несколько более исключительны чем другие. Причем если попытаться их классифицировать, то как и было сказано в самом начале главы, есть исключения родом из самого .NET приложения, а есть исключения родом из unsafe мира. Их в свою очередь можно разделить на две подкатегории: иcключительные ситуации ядра CLR (которое по своей сути — unsafe) и любой unsafe код внешних библиотек.
Давайте поговорим про эти особые исключительные ситуации.
Вообще, это может показаться не очевидным, но существует четыре типа Thread Abort.
Данная статья — третья из четырех в цикле статей про исключения. Полный цикл:
— Архитектура системы типов
— Cобытия об исключительных ситуациях
— Виды исключительных ситуаций (эта статья)
— Сериализация и блоки обработки
![[DotNetBook] События об исключительных ситуациях и как на пустом месте получить StackOverflow и ExecutionEngineException - 1](https://www.pvsm.ru/images/2018/08/16/DotNetBook-sobytiya-ob-isklyuchitelnyh-situaciyah-i-kak-na-pustom-meste-poluchit-StackOverflow-i-ExecutionEngineException.jpeg "[DotNetBook] События об исключительных ситуациях и как на пустом месте получить StackOverflow и ExecutionEngineException - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
В общем случае мы не всегда знаем о тех исключениях, которые произойдут в наших программах потому что практически всегда мы используем что-то, что написано другими людьми и что находится в других подсистемах и библиотеках. Мало того что возможны самые разные ситуации в вашем собственном коде, в коде других библиотек, так еще и существует множество проблем, связанных с исполнением кода в изолированных доменах. И как раз в этом случае было бы крайне полезно уметь получать данные о работе изолированного кода. Ведь вполне реальной может быть ситуация, когда сторонний код перехватывает все без исключения ошибки, заглушив их fault блоком:
try {
// ...
} catch {
// do nothing, just to make code call more safe
}В такой ситуации может оказаться что выполнение кода уже не так безопасно как выглядит, но сообщений о том что произошли какие-то проблемы мы не имеем. Второй вариант — когда приложение глушит некоторое, пусть даже легальное, исключение. А результат — следующее исключение в случайном месте вызовет падение приложения в некотором будущем от случайной казалось бы ошибки. Тут хотелось бы иметь представление, какая была предыстория этой ошибки. Каков ход событий привел к такой ситуации. И один из способов сделать это возможным — использовать дополнительные события, которые относятся к исключительным ситуациям: AppDomain.FirstChanceException и AppDomain.UnhandledException.
Данная статья — первая из четырех в цикле статей про исключения. Полный цикл:
— Архитектура системы типов
— Cобытия об исключительных ситуациях (эта статья)
— Виды исключительных ситуаций
— Сериализация и блоки обработки
![[DotNetBook]: Span, Memory и ReadOnlyMemory - 1](https://www.pvsm.ru/images/2018/08/13/DotNetBook-Span-Memory-i-ReadOnlyMemory.jpeg "[DotNetBook]: Span, Memory и ReadOnlyMemory - 1")
Этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
Визуальных отличий Memory<T> от Span<T> два. Первое — тип Memory<T> не содержит ограничения ref в заголовке типа. Т.е., другими словами, тип Memory<T> имеет право находиться не только на стеке, являясь либо локальной переменной либо параметром метода либо его возвращаемым значением, но и находиться в куче, ссылаясь оттуда на некоторые данные в памяти. Однако эта маленькая разница создает огромную разницу в поведении и возможностях Memory<T> в сравнении с Span<T>. В отличии от Span<T>, который представляет собой средство пользования неким буфером данных для некоторых методов, тип Memory<T> предназначен для хранения информации о буфере, а не для работы с ним.
Эта статья — вторая из цикла про Span<T> и Memory<T>. Она является вводной для Memory<T> в том плане что здесь я решил расписать общую терминилогию, а вот примеры совместного использования — решил вывести в отдельную статью
- Span<T>: новый тип данных .NET
- Span<T> и ReadOnlyMemory<T>
- Практика использования Span<T> и Memory<T>
![[DotNetBook] Исключения: архитектура системы типов - 1](https://www.pvsm.ru/images/2018/08/13/DotNetBook-isklyucheniya-arhitektura-sistemy-tipov.jpeg "[DotNetBook] Исключения: архитектура системы типов - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
Наверное, один из самых важных вопросов, который касается темы исключений — это вопрос построения архитектуры исключений в вашем приложении. Этот вопрос интересен по многим причинам. Как по мне так основная — это видимая простота, с которой не всегда очевидно, что делать. Это свойство присуще всем базовым конструкциям, которые используются повсеместно: это и IEnumerable, и IDisposable и IObservable и прочие-прочие. С одной стороны, своей простотой они манят, вовлекают в использование себя в самых разных ситуациях. А с другой стороны, они полны омутов и бродов, из которых, не зная, как иной раз и не выбраться вовсе. И, возможно, глядя на будущий объем у вас созрел вопрос: так что же такого в исключительных ситуациях?
![[DotNetBook] Структура экземпляров типов и VMT - 1](https://www.pvsm.ru/images/2017/12/13/DotNetBook-struktura-ekzemplyarov-tipov-i-VMT.jpeg "[DotNetBook] Структура экземпляров типов и VMT - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом.
Вся книга будет доступна на GitHub: CLR Book. Так что Issues и Pull Requests приветствуются :)
Это — выжимка из главы про структуру типов и их VMT.
До сих, говоря про разницу между значимыми и ссылочными типами, мы затрагивали эту тему с высоты конечного разработчика. Т.е. мы не смотрели на то как они в реальности устроены на уровне CLR, как сделаны те или иные механики внутри каждого из них. Мы смотрели фактически на конечный результат. Однако, чтобы понимать суть вещей глубже и чтобы отбросить в сторону последние оставшиеся мысли о какой-либо магии, происходящей внутри CLR стоит заглянуть в самые ее потроха.
Читать полностью »