1. Индексаторы могут использовать params параметры

public string this[string key]
 {
   get { return internalDictionary[key]; }
 }

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

Когда я рассказываю о том, над чем работаю, люди часто спрашивают меня, как я делаю игры, и их часто удивляет (а иногда и тревожит?), когда я говорю, что не пользуюсь коммерческими игровыми движками. Существует какой-то стереотип, что если ты делаешь игры не в популярном инструменте наподобие Unity или Unreal, это значит, что ты чуть ли не вручную пишешь ассемблерный код.

Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...

Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

Речь пойдет о проблемах, с которыми вы можете столкнуться при написании многопоточного кода, если вы думаете, что достаточно умны, чтоб спроектировать свои собственные механизмы синхронизации.

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.

Random numbers should not be generated with a method chosen at random.
— Donald Knuth

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

class AuthenticateByPhoneHandler
{
    /* ... */

    static string GenerateCode() => rnd.Next(100000, 1000000).ToString();

    readonly static Random rnd = new Random();
}

Проблема видна невооруженным глазом: для генерации 6-тизначного кода используется класс Random — простой некриптографический генератор псевдослучайных чисел (ГПСЧ). Займёмся им вплотную: научимся предсказывать последовательность случайных чисел и прикинем возможный сценарий атаки на сервис.

Потокобезопасность

Кстати, заметим, что в приведённом фрагменте кода доступ к статическому экземпляру rnd класса Random из нескольких потоков не синхронизирован. Это может привести к неприятному казусу, который можно часто встретить в вопросах и ответах на StackOverflow:

Инициализация свойств со значениями

Раньше:

public int Id { get; set; }
public string FirstName { get; set; }

Теперь:

public int Id { get; set; } = 1001;
public string FirstName { get; set; } = "Srinivas";

Я много раз слышал, как программисты смеются над тиммейтами, которые написали медленный код. Резкие, самодовольные фразы в стиле "этот болван четыре раза пробежался по коллекции, хотя можно было один", и тому подобное. Когда слышишь такое, сразу думаешь — ну тут все по делу, зачем делать лишние итерации? Почему нельзя изучить пару элементарных вещей, вроде принципов работы LINQ выражений в C#, и писать нормальный код? Ты смеешься над некомпетентными тупицами до тех пор, пока смеяться не начнут над тобой. И можете мне поверить — никакие знания в программировании не спасут вас от ситуации, когда вы по незнанию зафигачили квадратичный алгоритм вместо линейного.

Как известно, на любом языке можно писать, как на Java, а первая любовь джависта — это написание Garbage Collectors и JIT Compilers. С этим связано множество восхитительных вопросов, например: каким образом можно из управляемого кода напрямую работать с машинным кодом и ассемблером?

Кроме того, в этой статье будет небольшой пример на C#. В какой-то момент стало понятно, что нельзя всегда изучать одну Java. Рантаймы динамических языков используют общую теорию и на практике работают в рамках похожих проблем. Самый простой способ продвинуть свою работу — посмотреть, как там у соседей, и скопировать себе что-нибудь хорошее.

Теперь про ассемблер и машинный код. Зачем это нужно — вопрос открытый. Например, вы наслушались о Meltdown и хотите написать для него красивое API :-) Ну, и не надо забывать, что Oracle — не боги, поддержку того же AVX-512 добавили только в Девятке, прямое управление аппаратной транзакционной памятью не ложится на язык, часть стандартных методов можно реализовать лучше, чем это сделали в SDK и т.п. — у нас всегда есть с чем покопаться!

В последнее время на Хабре появляется достаточно много статей про Tarantool — базу данных и сервер приложений, который используется в Mail.Ru Group, Avito, Yota на разных высоконагруженных проектах. И вот, когда в маленьком стартапе, который я иногда консультирую, возникла необходимость разделения прекрасного, но, к сожалению, монолитного приложения на микросервисы, я подумал: а чем мы хуже других компаний? — и решил посмотреть в сторону Tarantool. Однако, в отличие от большинства компаний, где используется Tarantool, в нашем случае разработка проекта ведётся в Visual Studio на Windows. Предполагается, что даже с переходом на микросервисную архитектуру большинство микросервисов будет написано на языке C#. А Tarantool… Стоит зайти на официальный сайт — и сразу понимаешь: Tarantool даже установить на Windows проблематично, так как на эту операционную систему он не портирован. Как я боролся с такими сложностями, для какого именно микросервиса выбрал Tarantool и как вы можете использовать Tarantool в своих .NET-проектах, я расскажу в данной статье. А пока спойлер — практически все трудности преодолимы, и мой опыт можно без сомнений назвать положительным. Например, на то, чтобы скачать и запустить Tarantool, а потом сделать к нему запрос из кода на языке C#, у меня ушло менее десяти минут. И я покажу вам, как это сделать!

Данная статья представляет собой туториал, описывающий работу с Tarantool как таковую. Здесь нет описания проекта, построенного на Tarantool, или сравнения Tarantool с другими продуктами (статей на эту тему и так уже написано достаточно много). Материал родился как попытка ответить на вопрос: а что бы я хотел прочитать, когда только начинал работать с Tarantool. Но вначале немного расскажу, для чего мы, собственно, Tarantool применяем в реальной жизни.

Лирическое вступление

«Как организовать потокобезопасный вызов события в C# с учетом того, что большое количество потоков постоянно подписываются на событие и отписываются от него?»

Пишем синхронный сервер

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

Что это?