Не вижу ни слова о том, что такое Dmark, spf и dkim и как это работает. Только пример записи и первые пару строк описания из википедии. В чем смысл статьи? Для кого она?
Меня вот например в принципе раздражают собеседования формата вопрос-ответ, ибо собеседование процесс двусторонний, а такой формат просто убивает возможность понять, с кем придется работать и не позволяет ответить на главный вопрос, после собеседования — не мудак ли мой будущий начальник.
На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.
Вы по сути сделали нормализацию своей таблицы на стороне клиента, это слегка попахивает костылем. Не проще ли было, сделать это на стороне базы, и просто прочитать две таблицы?
Я их не путаю, у аппаратных исключений в отличие от программных просто другой источник, но механизм обработки в общем-то такой же.
Я не большой специалист в этих вопросах и видимо моих знаний недостаточно чтобы объяснить этот механизм. За более подробной информацией могу посоветовать посмотреть книгу Windows Internals глава Диспечеризация исключений.
все еще не правильный, возможность использования наследника вместо указанного типа не есть «преобразование в одну сторону». Преобразование типов возможно вообще без наследования например.
Возможно у вас проблемы с терминологией, но в нашем деле это очень важный аспект и нужно очень тщательно подбирать слова для описания процессов, особенно на русском.
Некоторые исключения система обрабатывает сама, собственно обработчик хранится в системной памяти.
Например используемый при отладке breakpoint вызывает исключение, которое ОС обрабатывает вызывая отладчик.
На сколько я знаю механизм обработки исключений в windows, требует перевода процессора в режим ядра (kernel mode), т.к. диспетчер исключений обращается системной памяти.
А по поводу делегатов я к сожалению не могу ничего сказать, я не знаю как они работаю внутри, но на сколько я понимаю делегаты не требуют обращения за пределы виртуальной памяти процесса, поэтому для их работы перевод процессора в режим ядра врятли происходит.
Я конечно не специалист, но разве у неупакованных ссылочных типов есть индекс блока синхронизации? По-моему как раз у них его и нет.
Вы скорее всего опечатались, механизм упаковки/распаковки существует только для value type.
У структурных типов и примитивных (byte,int,long...) нет блока синхронизации
У value type нет слова заголовка объекта, у reference type (в том числе упакованных value type) он есть — это основа основ, которую, я думал, знают все.
Исключения медленно работают, т.к. происходит переход в режим ядра.
Формально да, это так. Хотя определение «медленно» для разных задач разное, так что нужно просто сказать что происходит переключение контекста потока.
В целом статься получилась довольно сумбурной и содержит довольно много ошибок. Возможно автор злоупотреблял переводчиком или недостаточно понимает описываемые механизмы, но в любом случае статью нужно серьезно переработать.
Из ошибок которые сразу бросились в глаза это п.35 — VolatileWrite, VolatileRead — это не атомарные операции, по пункту Б — я даже не знаю как это написать, но в целом весь пункт сплошная ошибка. В англоязычной литературе взаимным запиранием называется мьютекс (Mutual Exclusion). Interlocked — класс предоставляет набор атомарных операций и не имеет ничего общего с мьютексом.
п.30 — написано не имеет отношения к ковариации и контравариации msdn.microsoft.com/ru-ru/library/dd799517(v=vs.110).aspx
На хабре уже был цикл статей по этой теме, вот ссылка на первый пост habrahabr.ru/post/97066/. Автору будет полезно прочитать, разобраться и упорядочить свои знания, а затем поправить данную статью.
1) Разве что OutOfMemoryException.
Это условие я добавил лишь для того, чтобы показать, что блокировать коллекцию на время перебора в данном случае невозможно, иначе рискуем потеряем часть данных.
2) Ничего подсказывать не нужно, я просто привел пример из своего опыта, хоть и немного притянутый за уши. (Задача давно решена, и она легко решается с использованием ConcurrentQueue, но пример с данной коллекцией не подойдет для обсуждения текущего вопроса, поэтому я попросил не использовать ее)
Я просто просил объяснения зачем запрещать изменять коллекцию на время перебора, вдруг я чего-то не понимаю, и мне не важно на каком вы примере это сделаете — моем, своем, или каком-то абстрактом. Вы почему-то слишком негативно настроены и придираетесь к деталям, хотя я просто просил пояснения.
Хорошо, вот пример. Есть несколько FileSystemWatcher'ов которые следят за несколькими папками и добавляют url файлов в ConcurrentDictionary, в другом потоке происходит перебор словаря и данные из него удаляются. Допустим в каждую папку падает до нескольких тысяч файлов в секунду. Учтем то, что время обработки события появления нового файла должно стремиться к 0, иначе мы получим переполнение внeтреннего буфера FileSystemWatcher'a.
Дополнительное условие не предлагать переделать на ConcurrentQueue или другую коллекцию, а рассматривать задачу именно так как она описана.
Ну представим на минуту, что у нас есть именно такая задача, хочу понять как и главное зачем вы предлагаете обеспечивать требование «не изменять коллекцию во время перебора»?
Я прошу прощения, бездумно взял ответ на ваш вопрос с ресурса , и там сказано следующее: 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 элемента и коллекция расширяется.
Постараюсь описать этот момент более подробно и включу в статью.
Да, 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)
На текущем месте, перед собеседованием сделал тестовое задание, а собеседование больше походило на дружескую беседу программистов о своем опыте и взглядах на штуки типа ооп, паттерны и прочие best practices, по ходу решил несколько задачек по алгоритмам и то не все до конца и мы обсудили какие еще есть варианты решения и написал на бумажке 20 строк кода. Ни одного вопроса по синтаксическим конструкциям, деталям реализации какой-нибудь фигни и прикладным технологиям не было, ибо правильно написали выше, любую технологию изучить не проблема, особенно если коллеги с ней знакомы.
Я не большой специалист в этих вопросах и видимо моих знаний недостаточно чтобы объяснить этот механизм. За более подробной информацией могу посоветовать посмотреть книгу Windows Internals глава Диспечеризация исключений.
Возможно у вас проблемы с терминологией, но в нашем деле это очень важный аспект и нужно очень тщательно подбирать слова для описания процессов, особенно на русском.
Например используемый при отладке breakpoint вызывает исключение, которое ОС обрабатывает вызывая отладчик.
На сколько я знаю механизм обработки исключений в windows, требует перевода процессора в режим ядра (kernel mode), т.к. диспетчер исключений обращается системной памяти.
А по поводу делегатов я к сожалению не могу ничего сказать, я не знаю как они работаю внутри, но на сколько я понимаю делегаты не требуют обращения за пределы виртуальной памяти процесса, поэтому для их работы перевод процессора в режим ядра врятли происходит.
Вы скорее всего опечатались, механизм упаковки/распаковки существует только для value type.
У value type нет слова заголовка объекта, у reference type (в том числе упакованных value type) он есть — это основа основ, которую, я думал, знают все.
Формально да, это так. Хотя определение «медленно» для разных задач разное, так что нужно просто сказать что происходит переключение контекста потока.
Из ошибок которые сразу бросились в глаза это п.35 — VolatileWrite, VolatileRead — это не атомарные операции, по пункту Б — я даже не знаю как это написать, но в целом весь пункт сплошная ошибка. В англоязычной литературе взаимным запиранием называется мьютекс (Mutual Exclusion). Interlocked — класс предоставляет набор атомарных операций и не имеет ничего общего с мьютексом.
п.30 — написано не имеет отношения к ковариации и контравариации msdn.microsoft.com/ru-ru/library/dd799517(v=vs.110).aspx
Это условие я добавил лишь для того, чтобы показать, что блокировать коллекцию на время перебора в данном случае невозможно, иначе рискуем потеряем часть данных.
2) Ничего подсказывать не нужно, я просто привел пример из своего опыта, хоть и немного притянутый за уши. (Задача давно решена, и она легко решается с использованием ConcurrentQueue, но пример с данной коллекцией не подойдет для обсуждения текущего вопроса, поэтому я попросил не использовать ее)
Я просто просил объяснения зачем запрещать изменять коллекцию на время перебора, вдруг я чего-то не понимаю, и мне не важно на каком вы примере это сделаете — моем, своем, или каком-то абстрактом. Вы почему-то слишком негативно настроены и придираетесь к деталям, хотя я просто просил пояснения.
Дополнительное условие не предлагать переделать на ConcurrentQueue или другую коллекцию, а рассматривать задачу именно так как она описана.
Правильно будет так: размер коллекции изменяется, когда количество элементов на одну блокировку превышает превышает значение m_budget.
На моем примере: у меня 4 процессора, соответственно размер массива m_locks = 16, а m_budget = 31/16 = 1. Как только мы вставляем 17 элемент, на одну блокировку теперь приходится 2 элемента и коллекция расширяется.
Постараюсь описать этот момент более подробно и включу в статью.
Увеличение размера массива в ConcurrentDictionary происходит, если количество элементов в одном из связных списков превысит разрешенное количество элементов на 1 lock. Это значение получается так: m_budget = m_tables.m_buckets.Length / m_tables.m_locks.Length; где m_tables.m_buckets — массив односвязных списков, m_tables.m_locks — массив с объектами для блокировок (размер этого массива по умолчанию равен число_процессоров*4)