Многопоточность и свойства. Часть 1

В однопоточном мире есть очень многие вещи, о которых мы даже не задумываемся. Например, в онлайн-игре вполне приемлемо такое описание здоровья «живого объекта» (NPC или игрока) на C#:

public int Health
{
    get { return m_health; }
    set { m_health = value; }
}

Когда наносится повреждение, следующий код вполне логичен:

int damage = 100;
target.Health -= damage;

if (target.Health <= 0)
{
    target.Die();
}

Т.е. мы вычитаем значение здоровья, затем сверяем, жива ли цель. Время идет, онлайн растет, процессоры дешевеют. Теперь у нас уже несколько многоядерных процессоров, тысячные онлайны, большая нагрузка. В этом свете один поток обработки выглядит архаичным и будет рано или поздно превращен в несколько конкурирующих потоков.
Если оставить указанный код без изменений в многопоточной модели, мы рано или поздно получим неприятные неожиданности. Чтобы было удобнее воспринимать, я преобразую работу со свойствами так, как делает это компилятор, но оставлю эту часть в формате C#:

int damage = 100;
int tmpHealth = target.get_Health();
target.set_Health(tmpHealth - damage);
if (target.get_Health() <= 0)
{
    target.Die();
}

Расписывать, почему Health -= превратилось в такого монстрика, тут я не буду – читайте Рихтера, MSDN. Гораздо важнее то, что в этих нескольких строках кода у нас несколько проблем синхронизации. Распишу в виде таблицы несколько вариантов развития событий с двумя потоками, которые одновременно пытаются сделать такую операцию. Для удобства скажем, что значение m_health изначально было равно 150, а damage для наших потоков 100 и 200 соответственно.

Вариант 1

Поток 1	Поток 2
int tmpHealth = target.get_Health(); значение tmpHealth = 150
	int tmpHealth =target.get_Health(); значение tmpHealth = 150
target.set_Health(tmpHealth - damage); значение m_health = 50
	target.set_Health(tmpHealth - damage); значение m_health = -50
if (target.get_Health() <= 0) {     target.Die(); } условие истинно, т.к. m_health уже -50, вызывается target.Die()
	if (target.get_Health() <= 0) {     target.Die(); } условие истинно, вызывается target.Die()

Вариант 2

Поток 1	Поток 2
int tmpHealth = target.get_Health(); значение tmpHealth = 150
target.set_Health(tmpHealth - damage); значение m_health = 50
	int tmpHealth = target.get_Health(); значение tmpHealth = 50
	target.set_Health(tmpHealth - damage); значение m_health = -150
	if (target.get_Health() <= 0) {     target.Die(); } условие истинно, вызывается target.Die()
if (target.get_Health() <= 0) {     target.Die(); } условие истинно, т.к. m_health = -150, вызывается target.Die()

Вариант 3

Поток 1	Поток 2
	int tmpHealth = target.get_Health(); значение tmpHealth = 150
int tmpHealth = target.get_Health(); значение tmpHealth = 150
	target.set_Health(tmpHealth - damage); значение m_health = -50
target.set_Health(tmpHealth - damage); значение m_health = 50
	if (target.get_Health() <= 0) {     target.Die(); } условие ложно, т.к. m_health = 50
if (target.get_Health() <= 0) {     target.Die(); } условие ложно

Это не все возможные варианты, но некоторые из них. Вне зависимости от количества процессоров, всегда есть вероятность, что в разных потоках один и тот же код будет выполнен в неудачном для нас порядке. В случае со здоровьем NPC это может привести к многократному вызову метода Die() или к потере результата одного из вызовов. Кто-то может предложить добавить блокировку в само свойство Health:

public int Health
{
    get
    {
        lock (m_healthLock)
            return m_health;
    }
    set
    {
        lock (m_healthLock)
            m_health = value;
    }
}

Но подобная блокировка не даст ничего, кроме строго указанного порядка записей/чтений, что в нашей задаче ничего не изменит. Правильным будет окружить сам метод блокировкой и двойной проверкой:

if (target.Health > 0)
    lock (taget.HealthLock)
        if (target.Health > 0)
        {
            int damage = 100;
            target.Health -= damage;

            if (target.Health <= 0)
            {
                target.Die();
            }
        }

Такой подход дает оптимальный результат, но влечет значительные изменения кода, а также работу с CriticalSection (вместе с ThinLock в .Net 2.0 и выше) при каждом обращении.
Конечно, было бы легче, если бы мы пользовались С++, а метод для получения здоровья возвращал ссылку или указатель, но подобных стандартных механизмов в C# нет (unsafe и указатели мы пока опустим). Также было бы проще, если бы Health было не свойством (property), а полем (field). В таком случае, мы бы поступили так:

int damage = 100;
if (Interlocked.Add(ref target.Health, -damage) > 0)
{
    target.Die();
}

Атомарная операция Interlocked.Add обеспечит нам выполнение вычитания без вмешательства других потоков, а также вернет старое новое значение переменной. Таким образом, мы без проблем сможем узнать, было ли именно это повреждение смертельным.
Мы отошли от принципов «красивого программирования» ради дополнительной производительности. В большей части случаев такой вариант приемлем, но у свойств есть еще одно полезное свойство – они могут быть виртуальными.
Например, в базовой реализации «живого объекта» мы имеем всю ту же работу с переменной:

public virtual int Health
{
    get { return m_health; }
    set { m_health = value; }
}

А в наследнике, реализующем игрока, запись уже идет в объект БД:

public override int Health
{
    get { return m_dbCharacter.Health; }
    set { m_dbCharacter.Health = value; }
}

Перейти к Interlocked методам в этом случае будет проблематично, потому самым разумным вариантом будет в таком случае перестать пользоваться свойством set напрямую (например, объявить его как protected в .Net 3.5) и сделать отдельный метод для изменения здоровья объекта:

void ModifyHealth(int value)
{
    if (Health > 0)
        lock (m_healthLock)
            if (Health > 0)
            {
                Health += value;

                if (Health <= 0)
                {
                    Die();
                }
            }
}

Хотелось бы использовать атомарные методы и в этой ситуации, но это уже проблематично, т.к. m_dbCharacter.Health в свою очередь вполне может быть свойством.
Наиболее производительным решением будет отказаться от виртуальности в таких свойствах, а объект БД обновлять в ключевых точках (при выходе из игры, при смерти и т.п.). Наиболее правильным решением будет отказ от использования публичных сеттеров для свойств, которые могут быть использованы в разных потоках. Разумным людям я советую остановиться на одном из этих вариантов. Остальным же (любителям нестандартных решений и «крестовых походов») я предложу несколько своих вариантов решения в следующих статьях на эту тему.


Update 03.04.08: Interlocked.Increment/Interlocked.Decrement не имеют второго параметра. Правильно пользоваться Interlocked.Add. Если кого сбил с толку - извиняюсь, самого бес попутал

Update 04.04.08: В ходе испытаний оказалось, что Interlocked.Add возвращает не старое, а новое значение. Это я проворонил, каюсь.