От переводчика

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

Под хабракатом — о том, что именно, помимо любви к Dune 2 подтолкнуло на создание Warcraft; почему в Warcraft такая яркая графика; какие здания не попали в Warcraft 1; откуда растут ноги у героев в Warcraft III и еще несколько интересностей, включая заднюю обложку коробки первого издания и несколько скринов для того, чтобы пустить слезу ностальгии.

Традиционно буду рад замечаниям, исправлениям. И спасибо всем, кто писал по этому поводу в прошлый раз!

Простой макрос

Все началось с простого макроса: (приблизительный код)

#define ADD_BYTE(C) do {            \
  if (offset == capa) {             \
    if (capa < 16) {                \
      capa = 16;                    \
    } else {                        \
      capa <<= 1;                   \
    }                               \
    buffer = realloc(buffer, capa); \
    assert(buffer != NULL);         \
  }                                 \
  buffer[offset++] = (C);           \
} while(0)

Для тех, кто не знаком с языком программирования C, поясню: этот простой макрос добавляет байт «C» в динамически выделяемый буфер (buffer), размер которого (в байтах) равен capa. Следующая позиция для записи определяется при помощи параметра offset. При каждом заполнении буфера происходит двукратное увеличение его объема (начиная с минимального размера в 16 байт).

Мы добавляем байты в динамический буфер — это одна из наиболее распространенных операций практически в любой программе (для работы со строками, массивами и т. п.).

Но как понять, насколько эффективна стратегия перераспределения?

Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:


Рисунок 1 – Структурная схема работы X allocator

Из схемы видно, что доступ к глобальной куче защищен мьютексом. Такая архитектура, при интенсивном создании однотипных объектов из нескольких потоков, может привести к тому, что потоки будут вставать в очередь на этом мьютексе. А ведь одна из главных особенностей продукта – это возможность его масштабирования за счет увеличения количества потоков обработки (потоков выполняющих одинаковые действия). Поэтому такой подход потенциально может стать узким местом.

Построение lock-free структур данных зиждется на двух китах – атомарных операциях и способах упорядочения доступа к памяти. В этой статье речь пойдет об атомарности и атомарных примитивах.

Анонс. Спасибо за теплый прием Начал! Вижу, что тема lock-free интересна хабрасообществу, это меня радует. Я планировал построить цикл по академическому принципу, плавно переходя от основ к алгоритмам, попутно иллюстрируя текст кодом из libcds. Но часть читателей требует зрелищ не мешкая показать, как пользоваться библиотекой, особо не рассусоливая. Я согласен, в этом есть свой резон. В конечном счете, и мне не так интересно, что там внутри boost, — опишите, как его применять! Поэтому свой эпический цикл я разделю на три части: Основы, Внутри и Извне. Каждая статья эпопеи будет относится к одной из частей. В Основах будет рассказываться о низкоуровневых вещах, вплоть до строения современных процессоров; это часть для почемучек вроде меня. Внутри будет освещать интересные алгоритмы и подходы в мире lock-free, — это скорее теория о том, как реализовать lock-free структуру данных, libcds будет неисчерпаемым источником C++ кода. В Извне будут статьи о практике применения libcds, — программные решения, советы и FAQ. Извне будет питаться вашими вопросами/замечаниями/предложениями, дорогие хабражители.

А пока я судорожно готовлю начало Извне, — первая часть Основ. Статья во многом не о C++ (хотя и о нем тоже) и даже не о lock-free (хотя без atomic lock-free алгоритмы неработоспособны), а о реализации атомарных примитивов в современных процессорах и о базовых проблемах, возникающих при использовании таких примитивов.
Атомарность — это первый круг ада низкий уровень из двух.

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

В статье описана установка под Ubuntu. Используется приложение от Google.

21 июня 2011 года Nokia представила смартфон N9 с операционной системой MeeGo Harmattan на борту. Смею утверждать, что N9, — единственный вау-продукт после появления на рынке iPhone. Но на момент презентации N9 уже было известно, что финский IT-гигант заключил долгосрочный союз с корпорацией Microsoft, и N9 станет первым и единственным смартфоном Nokia на MeeGo Harmattan.

Давайте представим себе типичный, набирающий популярность стартап, использующий, например, PHP или Python. Сначала все находится на одном сервере — PHP (или Python), Apache, MySQL. Затем вы выносите MySQL на отдельный сервер, устанавливаете nginx для раздачи контента, возможно, добавляете memcached для кеширования и еще несколько серверов приложений…

Со временем число серверов будет расти, и рано или поздно вы зададитесь вопросами
«А что сейчас вообще происходит с системой? Как часто выполняется тот или иной скрипт и как долго? Какие операции занимают большую часть времени?» Системы мониторинга типа Zabbix дают лишь общую, поверхностную картину состояния приложения.

Чтобы получить ответы на эти вопросы, в Badoo был разработан сервиc мониторинга и статистики в реальном времени — Pinba. В данной статье мы расскажем о нашем опыте использования его для мониторинга и профайлинга нашей системы.

Многие сталкивались с таким явлением как DDoS атака методом HTTP флуда. Нет, это не очередной туториал по настройке nginx, хочу представить свой модуль, работающий как быстрый фильтр между ботами и бэкэндом во время L7 DDoS атаки и позволяющий отсеивать мусорные запросы.

Как известно, при разработке высоконагруженных серверов часто применяется событийная модель работы с сокетами. Ключевым компонентом системы при этом является epoll (во FreeBSD и Windows есть свои решения, но остановимся на Линуксе). Функция epoll_wait, будучи единственным блокирующим вызовом, возвращает нам информацию обо всех сетевых событиях, которые нас интересуют. Подобным образом, конечно, работает и всем известный сервер NGINX.

Событийная модель программирования делает код весьма своеобразным, как будто выворачивает его наизнанку. Но эта проблема не так страшна. Есть другая проблема — использование в событийно-ориентированном коде существующих библиотек, изначально не предназначенных для него. Если подобная библиотека делает блокирующие вызовы (например, connect, recv и т.д.), вся событийная модель может потерять смысл т.к. окончания одного такого вызова будут ждать все остальные клиенты, что совершенно неприемлемо, если вы пишете серьезный продукт.