• Доставка миллиардов сообщений строго один раз
    0
    На каждый партишен в топике свой воркер и только в одном экземпляре, я правильно понял?
  • Настройка DKIM/SPF/DMARC записей или защищаемся от спуфинга
    +3
    Не вижу ни слова о том, что такое Dmark, spf и dkim и как это работает. Только пример записи и первые пару строк описания из википедии. В чем смысл статьи? Для кого она?
  • Навыки .NET-разработчика России и США, в чем разница?
    +4
    меня одного смущает, что node.js стоит в одном ряду с angular, knockout и прочими?
  • Техническое собеседование: пять способов отпугнуть соискателя / пять способов взбесить интервьюера
    +5
    Меня вот например в принципе раздражают собеседования формата вопрос-ответ, ибо собеседование процесс двусторонний, а такой формат просто убивает возможность понять, с кем придется работать и не позволяет ответить на главный вопрос, после собеседования — не мудак ли мой будущий начальник.
    На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.
  • Оптимизация DataTable по памяти
    0
    Вы по сути сделали нормализацию своей таблицы на стороне клиента, это слегка попахивает костылем. Не проще ли было, сделать это на стороне базы, и просто прочитать две таблицы?
  • Интересные заметки по C# и CLR
    0
    Я их не путаю, у аппаратных исключений в отличие от программных просто другой источник, но механизм обработки в общем-то такой же.
    Я не большой специалист в этих вопросах и видимо моих знаний недостаточно чтобы объяснить этот механизм. За более подробной информацией могу посоветовать посмотреть книгу Windows Internals глава Диспечеризация исключений.
  • Интересные заметки по C# и CLR
    +1
    все еще не правильный, возможность использования наследника вместо указанного типа не есть «преобразование в одну сторону». Преобразование типов возможно вообще без наследования например.
    Возможно у вас проблемы с терминологией, но в нашем деле это очень важный аспект и нужно очень тщательно подбирать слова для описания процессов, особенно на русском.
  • Интересные заметки по C# и CLR
    0
    Некоторые исключения система обрабатывает сама, собственно обработчик хранится в системной памяти.
    Например используемый при отладке breakpoint вызывает исключение, которое ОС обрабатывает вызывая отладчик.
  • Интересные заметки по C# и CLR
    0
    Но при чем тут вообще режим ядра?

    На сколько я знаю механизм обработки исключений в windows, требует перевода процессора в режим ядра (kernel mode), т.к. диспетчер исключений обращается системной памяти.
    А по поводу делегатов я к сожалению не могу ничего сказать, я не знаю как они работаю внутри, но на сколько я понимаю делегаты не требуют обращения за пределы виртуальной памяти процесса, поэтому для их работы перевод процессора в режим ядра врятли происходит.
  • Интересные заметки по C# и CLR
    0
    Я конечно не специалист, но разве у неупакованных ссылочных типов есть индекс блока синхронизации? По-моему как раз у них его и нет.

    Вы скорее всего опечатались, механизм упаковки/распаковки существует только для value type.
    У структурных типов и примитивных (byte,int,long...) нет блока синхронизации

    У value type нет слова заголовка объекта, у reference type (в том числе упакованных value type) он есть — это основа основ, которую, я думал, знают все.
    Исключения медленно работают, т.к. происходит переход в режим ядра.

    Формально да, это так. Хотя определение «медленно» для разных задач разное, так что нужно просто сказать что происходит переключение контекста потока.
  • Интересные заметки по C# и CLR
    +8
    В целом статься получилась довольно сумбурной и содержит довольно много ошибок. Возможно автор злоупотреблял переводчиком или недостаточно понимает описываемые механизмы, но в любом случае статью нужно серьезно переработать.
    Из ошибок которые сразу бросились в глаза это п.35 — VolatileWrite, VolatileRead — это не атомарные операции, по пункту Б — я даже не знаю как это написать, но в целом весь пункт сплошная ошибка. В англоязычной литературе взаимным запиранием называется мьютекс (Mutual Exclusion). Interlocked — класс предоставляет набор атомарных операций и не имеет ничего общего с мьютексом.
    п.30 — написано не имеет отношения к ковариации и контравариации msdn.microsoft.com/ru-ru/library/dd799517(v=vs.110).aspx
  • Предлагаю нестандартный опросник по .Net
    0
    А вы задумываетесь о быстродействии когда объявляете счетчик? Я нет, но я буду задумываться о том, что передавая его в метод он будет копироваться.
    Эрик Липперт со мной согласен :D blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx
  • Предлагаю нестандартный опросник по .Net
    0
    90% случаев использования value types это такие штуки типа int counter = 0; и в этом случае семантика — единственное что должно вас беспокоить. А вот оставшиеся 10, а возможно и меньше — это использование структур ради быстродействия, и то в этом случае важно учитывать семантику, ибо постоянное копирование объектов только снизит производительность приложения.
  • Предлагаю нестандартный опросник по .Net
    0
    По поводу отличия Value и Reference типов всегда отвечаю, что различия только в семантике, ибо названия весьма четко отражают их суть, а размещение в памяти лишь деталь реализации. Да и если мне память не изменяет, массивы могут быть размещены в стеке в unsafe контексте с помощью stackalloc или объявить его fixed внутри структуры
  • Электронная подпись. История появления и развития
    +1
    На хабре уже был цикл статей по этой теме, вот ссылка на первый пост habrahabr.ru/post/97066/. Автору будет полезно прочитать, разобраться и упорядочить свои знания, а затем поправить данную статью.
  • Изменение ConcurrentDictionary во время перебора
    +2
    1) Разве что OutOfMemoryException.
    Это условие я добавил лишь для того, чтобы показать, что блокировать коллекцию на время перебора в данном случае невозможно, иначе рискуем потеряем часть данных.
    2) Ничего подсказывать не нужно, я просто привел пример из своего опыта, хоть и немного притянутый за уши. (Задача давно решена, и она легко решается с использованием ConcurrentQueue, но пример с данной коллекцией не подойдет для обсуждения текущего вопроса, поэтому я попросил не использовать ее)
    Я просто просил объяснения зачем запрещать изменять коллекцию на время перебора, вдруг я чего-то не понимаю, и мне не важно на каком вы примере это сделаете — моем, своем, или каком-то абстрактом. Вы почему-то слишком негативно настроены и придираетесь к деталям, хотя я просто просил пояснения.
  • Изменение ConcurrentDictionary во время перебора
    0
    Хорошо, вот пример. Есть несколько FileSystemWatcher'ов которые следят за несколькими папками и добавляют url файлов в ConcurrentDictionary, в другом потоке происходит перебор словаря и данные из него удаляются. Допустим в каждую папку падает до нескольких тысяч файлов в секунду. Учтем то, что время обработки события появления нового файла должно стремиться к 0, иначе мы получим переполнение внeтреннего буфера FileSystemWatcher'a.
    Дополнительное условие не предлагать переделать на ConcurrentQueue или другую коллекцию, а рассматривать задачу именно так как она описана.
  • Изменение ConcurrentDictionary во время перебора
    0
    Ну представим на минуту, что у нас есть именно такая задача, хочу понять как и главное зачем вы предлагаете обеспечивать требование «не изменять коллекцию во время перебора»?
  • Изменение ConcurrentDictionary во время перебора
    +1
    А как вы это можете гарантировать в случае многопоточной среды? Брать lock перед каждым циклом foreach не самое удачное решение на мой взгляд.
  • Изменение ConcurrentDictionary во время перебора
    +1
    Я прошу прощения, бездумно взял ответ на ваш вопрос с ресурса , и там сказано следующее: the buckets array has to be resized once the number of items in each bucket has gone over a certain limit. (In ConcurrentDictionary this limit is when the size of the largest bucket is greater than the number of buckets for each lock. This check is done at the end of the TryAddInternal method.). Но это ошибочное утверждение.
    Правильно будет так: размер коллекции изменяется, когда количество элементов на одну блокировку превышает превышает значение m_budget.
    На моем примере: у меня 4 процессора, соответственно размер массива m_locks = 16, а m_budget = 31/16 = 1. Как только мы вставляем 17 элемент, на одну блокировку теперь приходится 2 элемента и коллекция расширяется.
    Постараюсь описать этот момент более подробно и включу в статью.
  • Изменение ConcurrentDictionary во время перебора
    0
    Да, 18 элемент, спасибо, поправил.
    Увеличение размера массива в ConcurrentDictionary происходит, если количество элементов в одном из связных списков превысит разрешенное количество элементов на 1 lock. Это значение получается так: m_budget = m_tables.m_buckets.Length / m_tables.m_locks.Length; где m_tables.m_buckets — массив односвязных списков, m_tables.m_locks — массив с объектами для блокировок (размер этого массива по умолчанию равен число_процессоров*4)