У нас есть небольшой объем данных, который разделяется между несколькими процессами. Одним из способов защиты данных является использование примитива взаимоисключающей блокировки SpinLock. Однако этот подход может привести к взаимоблокировке, если процесс, владеющий примитивом SpinLock, не имеет возможности освободить его. Например, он может быть приостановлен отладчиком или кто-то может вызвать функцию TerminateProcess для того, чтобы уничтожить этот процесс.

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

Эта задача может быть разрешена при помощи шаблона «Издатель – подписчик». Когда издателю нужно обновить значения, он уведомляет подписчиков об этом, просто сообщая им местоположение обновленных данных.

Давайте предположим, что разделяемые данные являются коллекцией четырех целых чисел типа int.

struct SHAREDDATA {
  int a, b, c, d;
};

Также предположим, что существует некоторый лимит на частоту изменения этих данных. Это предположение, обычно, является допустимым, потому что в подобных ситуациях присутствует какое-либо внешнее ограничение, вроде: «Это значение изменяется в результате некоторого действия пользователя». (Даже если такой лимит отсутствует, большинство реализаций просто устанавливают какое-либо собственное значение в качестве лимита. К примеру, функции SLIST предполагают, что процессор не будет заблокирован более чем 65535 раз подряд). Давайте предположим, что в нашем случае значение не будет изменяться более чем 64 раза в расчете на одну операцию чтения.

#define SHAREDDATA_MAXCONCURRENT 64

SHAREDDATA g_rgsd[SHAREDDATA_MAXCONCURRENT];
UINT g_isd; // текущее местоположение корректного значения

void GetSharedData(__out SHAREDDATA *psd)
{
  *psd = g_rgsd[g_isd];
}

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

Хотя, на самом деле, не так уж это и сложно.

LONG g_isdNext = 1;

void UpdateSharedData(__in const SHAREDDATA *psd)
{
  UINT isd = (UINT)InterlockedIncrementAcquire(&g_isdNext);
  isd %= SHAREDDATA_MAXCONCURRENT;
  g_rgsd[isd] = *psd;
  InterlockedExchange(&g_isd, isd);
}

Публикация данных заключается в простом получении слота для данных при помощи функции InterlockedIncrement, которая вернет нам уникальное местоположение для сохраняемых данных, или, по крайней мере, уникальное в течение SHAREDDATA_MAXCONCURRENT – 1 промежуточных публикаций. Мы сохраняем наши результаты в полученный нами слот памяти, а затем публикуем новый индекс. Публикация должна быть осуществлена с применением семантики освобождения (Release semantics), но поскольку другие вызовы функции InterlockedExchangeRelease отсутствуют, то мы просто выполним обновление значения с использованием полного барьера памяти.

Обратите внимание, что обновление данных не является атомарной операцией с точки зрения их считывания. Процессор может выполнить функцию GetSharedData, обработать полученные значения, а затем опубликовать их, перезаписывая тем самым публикацию, производимую в это время другим процессором. Если новые значения зависят от старых (например, если они являются нарастающим итогом), то в таком случае вы только что потеряли одно обновление данных.

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

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

Упражнение: как бы вы изменили это решение, если бы новые значения зависели от старых?

У нас есть небольшой объем данных, который разделяется между несколькими процессами. Одним из способов защиты данных является использование примитива взаимоисключающей блокировки SpinLock. Однако этот подход может привести к взаимоблокировке, если процесс, владеющий примитивом SpinLock, не имеет возможности освободить его. Например, он может быть приостановлен отладчиком или кто-то может вызвать функцию TerminateProcess для того, чтобы уничтожить этот процесс.

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

Эта задача может быть разрешена при помощи шаблона «Издатель – подписчик». Когда издателю нужно обновить значения, он уведомляет подписчиков об этом, просто сообщая им местоположение обновленных данных.

Давайте предположим, что разделяемые данные являются коллекцией четырех целых чисел типа int.

struct SHAREDDATA {
  int a, b, c, d;
};

Также предположим, что существует некоторый лимит на частоту изменения этих данных. Это предположение, обычно, является допустимым, потому что в подобных ситуациях присутствует какое-либо внешнее ограничение, вроде: «Это значение изменяется в результате некоторого действия пользователя». (Даже если такой лимит отсутствует, большинство реализаций просто устанавливают какое-либо собственное значение в качестве лимита. К примеру, функции SLIST предполагают, что процессор не будет заблокирован более чем 65535 раз подряд). Давайте предположим, что в нашем случае значение не будет изменяться более чем 64 раза в расчете на одну операцию чтения.

#define SHAREDDATA_MAXCONCURRENT 64

SHAREDDATA g_rgsd[SHAREDDATA_MAXCONCURRENT];
UINT g_isd; // текущее местоположение корректного значения

void GetSharedData(__out SHAREDDATA *psd)
{
  *psd = g_rgsd[g_isd];
}

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

Хотя, на самом деле, не так уж это и сложно.

LONG g_isdNext = 1;

void UpdateSharedData(__in const SHAREDDATA *psd)
{
  UINT isd = (UINT)InterlockedIncrementAcquire(&g_isdNext);
  isd %= SHAREDDATA_MAXCONCURRENT;
  g_rgsd[isd] = *psd;
  InterlockedExchange(&g_isd, isd);
}

Публикация данных заключается в простом получении слота для данных при помощи функции InterlockedIncrement, которая вернет нам уникальное местоположение для сохраняемых данных, или, по крайней мере, уникальное в течение SHAREDDATA_MAXCONCURRENT – 1 промежуточных публикаций. Мы сохраняем наши результаты в полученный нами слот памяти, а затем публикуем новый индекс. Публикация должна быть осуществлена с применением семантики освобождения (Release semantics), но поскольку другие вызовы функции InterlockedExchangeRelease отсутствуют, то мы просто выполним обновление значения с использованием полного барьера памяти.

Обратите внимание, что обновление данных не является атомарной операцией с точки зрения их считывания. Процессор может выполнить функцию GetSharedData, обработать полученные значения, а затем опубликовать их, перезаписывая тем самым публикацию, производимую в это время другим процессором. Если новые значения зависят от старых (например, если они являются нарастающим итогом), то в таком случае вы только что потеряли одно обновление данных.

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

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

Упражнение: как бы вы изменили это решение, если бы новые значения зависели от старых?

На самом деле, в наиболее простых функциях однократной инициализации блокировки используются, но при этом они реализованы по шаблону блокировки с двойной проверкой, что позволяет вам не заботиться об этих деталях. Алгоритм использования функции InitOnceExecuteOnce является довольно простым. Вот самый примитивный вариант его использования:

int SomeGlobalInteger;

BOOL CALLBACK ThisRunsAtMostOnce(
    PINIT_ONCE initOnce,
    PVOID Parameter,
    PVOID *Context)
{
    calculate_an_integer(&SomeGlobalInteger);
    return TRUE;
}

void InitializeThatGlobalInteger()
{
    static INIT_ONCE initOnce = INIT_ONCE_STATIC_INIT;
    InitOnceExecuteOnce(&initOnce,
                        ThisRunsAtMostOnce,
                        nullptr, nullptr);
}

В этом самом простом варианте вы передаете функции InitOnceExecuteOnce структуру INIT_ONCE (в которую функция записывает свое состояние) и ссылку на функцию обратного вызова. Если функция InitOnceExecuteOnce для заданной структуры INIT_ONCE выполняется впервые, она вызывает функцию обратного вызова. Функция обратного вызова может делать все, что ей заблагорассудится, но, скорее всего, она будет производить некоторую инициализацию, которая должна выполняться однократно. Если функция InitOnceExecuteOnce для той же самой структуры INIT_ONCE будет вызвана другим потоком, выполнение этого потока будет приостановлено до тех пор, пока первый поток не закончит выполнение своего инициализационного кода.

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

BOOL CALLBACK ThisSucceedsAtMostOnce(
    PINIT_ONCE initOnce,
    PVOID Parameter,
    PVOID *Context)
{
    return SUCCEEDED(calculate_an_integer(&SomeGlobalInteger));
}

BOOL TryToInitializeThatGlobalInteger()
{
    static INIT_ONCE initOnce = INIT_ONCE_STATIC_INIT;
    return InitOnceExecuteOnce(&initOnce,
                               ThisSucceedsAtMostOnce,
                               nullptr, nullptr);
}

Если ваша инициализационная функция вернет FALSE, то инициализация будет считаться неуспешной и когда в следующий раз кто-нибудь вызовет функцию InitOnceExecuteOnce, она снова попытается выполнить инициализацию. Еще чуточку более интересный вариант использования функции InitOnceExecuteOnce принимает во внимание параметр Context. Парни из команды разработки ядра Windows заметили, что структура INIT_ONCE в состоянии «проинициализировано» содержит множество неиспользуемых битов, и они предложили вам использовать их для собственных нужд. Это довольно удобно в том случае, когда то, что вы инициализируете, является указателем на объект C++, потому что это означает, что теперь вам нужно заботиться лишь об одной вещи вместо двух.

BOOL CALLBACK AllocateAndInitializeTheThing(
    PINIT_ONCE initOnce,
    PVOID Parameter,
    PVOID *Context)
{
    *Context = new(nothrow) Thing();
    return *Context != nullptr;
}

Thing *GetSingletonThing(int arg1, int arg2)
{
    static INIT_ONCE initOnce = INIT_ONCE_STATIC_INIT;
    void *Result;
    if (InitOnceExecuteOnce(&initOnce,
                            AllocateAndInitializeTheThing,
                            nullptr, &Result))
    {
        return static_cast<Thing*>(Result);
    }
    return nullptr;
}

Последний параметр функции InitOnceExecuteOnce принимает «волшебные» данные, по размеру почти идентичные указателю, которые функция запомнит для вас. Затем ваша функция обратного вызова передает эти «волшебные» данные обратно, через параметр Context, а функция InitOnceExecuteOnce возвращает их вам в виде параметра Result. Как и в предыдущем случае, если два потока вызовут функцию InitOnceExecuteOnce одновременно, используя неинициализированную структуру INIT_ONCE, один из них вызывет функцию инициализации, а другой поток будет приостановлен.

До этого момента мы рассматривали шаблоны синхронной инициализации. Для своей работы они используют блокировки: если вы вызовете функцию InitOnceExecuteOnce в тот момент, когда производится инициализация структуры INIT_ONCE, этот вызов будет ожидать завершения текущей попытки инициализации (вне зависимости от того, будет ли она успешной или окончится неудачей).

Гораздо интересней асинхронный шаблон. Вот пример такого шаблона применительно к нашей задаче с классом SingletonManager:

  SingletonManager(const SINGLETONINFO *rgsi, UINT csi)
                : m_rgsi(rgsi), m_csi(csi),
                  m_rgio(new INITONCE[csi]) {
    for (UINT iio = 0; iio < csi; iio++) {
      InitOnceInitialize(&m_rgio[iio]);
    }
  }
  ...
  // Массив, описывающий созданные объекты
  // объекты в этом массиве расположены параллельно элементам массива m_rgsi
  INIT_ONCE *m_rgio;
};

ITEMCONTROLLER *SingletonManager::Lookup(DWORD dwId)
{
  ... все точно так же, как и в предыдущем варианте, вплоть до того места,
  где начинается реализация шаблона «singleton-конструктор»

  void *pv = NULL;
  BOOL fPending;
  if (!InitOnceBeginInitialize(&m_rgio[i], INIT_ONCE_ASYNC,
                               &fPending, &pv)) return NULL;

  if (fPending) {
    ITEMCONTROLLER *pic = m_rgsi[i].pfnCreateController();
    DWORD dwResult = pic ? 0 : INIT_ONCE_INIT_FAILED;
    if (InitOnceComplete(&m_rgio[i],
                         INIT_ONCE_ASYNC | dwResult, pic)) {
      pv = pic;
    } else {
      // проиграл в гонке — теперь уничтожь ненужную копию и получи результат победителя
      delete pic;
      InitOnceBeginInitialize(&m_rgio[i], INIT_ONCE_CHECK_ONLY,
                              X&fPending, &pv);
    }
  }
  return static_cast<ITEMCONTROLLER *>(pv);
}

Таким образом, шаблон для асинхронной инициализации состоит из следующих шагов:

• Вызовите функцию InitOnceBeginInitialize в асинхронном режиме.
• Если она вернет fPending == FALSE, значит инициализация уже была произведена и вы можете использовать результат, переданный в качестве последнего параметра.
• В противном случае инициализация еще не выполнялась (или еще не завершилась). Выполните свою инициализацию, но помните, что поскольку это алгоритм без использования блокировок, может оказаться, что эту инициализацию в данный момент выполняют еще несколько других потоков, следовательно, вам нужно быть очень осторожными с операциями над объектами, хранящими глобальное состояние. Этот шаблон работает лучше всего, когда инициализация реализована в виде создания нового объекта (потому что в этом случае, если несколько потоков будут выполнять инициализацию, каждый из них будет создавать отдельный независимый объект).
• Вызовите InitOnceComplete с результатами вашей инициализации.
• Если выполнение функции InitOnceComplete завершится успешно, значит вы выиграли гонку и на этом процедура инициализации закончена.
• Если выполнение функции InitOnceComplete закончится неудачей, значит вы проиграли инициализационную гонку и должны отменить результаты вашей неуспешной инициализации. Также в этом случае вам нужно вызвать InitOnceBeginInitialize еще один, последний раз, для того, чтобы получить результат инициализации, выполненной в потоке, который выиграл гонку.

Несмотря на то, что описание алгоритма довольно объемно, с концептуальной точки зрения он довольно прост. По крайней мере, теперь он написан в форме пошаговой инструкции.

Упражнение: что будет, если вместо вызова InitOnceComplete со значением INIT_ONCE_INIT_FAILED функция просто вернет управление без завершения однократной инициализации?

Упражнение: что будет, если два потока попытаются выполнить асинхронную инициализацию и поток, который первым дойдет до конечного этапа инициализации, потерпит неудачу?

Упражнение: объедините результаты двух предыдущих упражнений и предположите, что получится в итоге.

// предположим, что все допустимые значения переменных a и b удовлетворяют условиям:
// a ≥ 0 и b ≥ a. Таким образом, -1 не является допустимым значением
// и мы будем использовать его для того, чтобы обозначить,
// что эта переменная еще не проинициализирована.
int a = -1, b = -1;

void LazyInitialize()
{
  if (a != -1) return; // уже проинициализировано

  a = calculate_nominal_a();
  b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  a = max(0, a);
  b = max(a, b);
}

Этот код отлично работает в однопоточной программе, но если программа будет многопоточной, может возникнуть такая ситуация, когда два потока попытаются одновременно проинициализировать переменные, что приведет к состоянию гонки (race conditions). В результате один из потоков будет использовать значения переменных до того, как они будут проинициализированы:

Обратите внимание, что в случае, когда Поток 1 первым получил управление, то после операции записи значения в переменную a второй поток будет считать, что все уже проинициализировано и может сделать попытку использования неинициализированной переменной b.

«Ага», — скажете вы, — «это несложно исправить. Я просто буду использовать переменную b вместо a для того, чтобы обозначить, что инициализация уже завершена».

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано (проверяем b, а не a)

  a = calculate_nominal_a();
  b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  a = max(0, a);
  b = max(a, b);
}

Это все равно не исключает состояния гонки:

«И это я могу исправить. Я просто посчитаю значения a и b и сохраню их в локальных переменных, а глобальные переменные буду обновлять только после того, как будут посчитаны окончательные значения. В этом случае второй поток не увидит частично вычисленные значения».

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано

  // производим все вычисления и сохраняем их сначала в локальных переменных
  int temp_a = calculate_nominal_a();
  int temp_b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  temp_a = max(0, temp_a);
  temp_b = max(temp_a, temp_b);

  // делаем временные значения постоянными
  a = temp_a;
  b = temp_b;
}

Почти правильно, но все равно возникает состояние гонки:

Нет никаких гарантий того, что результат операции присвоения b = 2 станет видимым для остальных процессоров строго после операции присвоения a = 2. Даже несмотря на то, что операции сохранения значений инициируются в нужном нам порядке, контроллер памяти может выполнить эти операции в обратном порядке, что приведет к тому, что Поток 2 увидит значения a = -1 и b = 2.

Для того чтобы такого не происходило, запись в переменную b должна производиться с семантикой освобождения (Release semantics), требующей, чтобы все предыдущие операции записи в память завершились прежде, чем результат операции записи значения в переменную b станет виден другим процессорам.

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано

  // производим все вычисления и сохраняем их сначала в локальных переменных
  int temp_a = calculate_nominal_a();
  int temp_b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  temp_a = max(0, temp_a);
  temp_b = max(temp_a, temp_b);

  // делаем временные значения постоянными
  a = temp_a;
  // поскольку мы используем переменную b в качестве индикатора
  // завершения инициализации, мы должны присваивать ей значение в последнюю очередь
  // и использовать при этом семантику освобождения.
  InterlockedCompareExchangeRelease(
        reinterpret_cast<LONG*>&b, temp_b, -1);
}

Если вы взглянете на окончательный результат, вы заметите, что он является повторным изобретением шаблона singleton-инициализации, который гласит: выполните набор вычислений где-нибудь в сторонке, а затем опубликуйте результат в рамках единственной операции InterlockedCompareExchangeRelease.

Следовательно, общий шаблон будет следующим:

void LazyInitializePattern()
{
  if (глобальная_сигнальная_переменная != маркерное_значение) return;

  ... выполнение вычислений и запись результатов в локальные переменные ...

  глобальная_переменная1 = временная_переменная1;
  глобальная_переменная2 = временная_переменная2;
  ...
  глобальная_переменнаяN = временная_переменнаяN;

  // и в последнюю очередь — публикация сигнальной переменной
  // с использованием семантики освобождения для гарантии того,
  // что значения предыдущих переменных также будут видны
  InterlockedCompareExchangeRelease(
        reinterpret_cast<LONG*>&глобальная_сигнальная_переменная,
        временная_сигнальная_переменная, маркерное_значение);
}

Если это чересчур для вас (и учитывая то, что я в первый раз напортачил с коварной двойной проверкой-блокировкой, это чересчур и для меня), вы можете положиться на команду разработки ядра Windows, поручив ей думать обо всех этих деталях, и вместо написания этого кода вручную использовать готовые функции для однократной инициализации, инкапсулирующие всю эту логику. (Мой приятель Дорон (Doron) некоторое время назад обнародовал информацию об этих функциях однократной инициализации). Четвертая версия .NET Framework содержит соответствующую функциональность в классе Lazy<T>.

Упражнение: какие скрытые предположения были сделаны относительно функций calculate_nominal_a и calculate_nominal_b?

Упражнение: какими будут последствия, если мы будем использовать функцию InterlockedExchange вместо функции InterlockedCompareExchangeRelease?

Упражнение: действительно ли нужны переменные temp_a и temp_b в окончательной версии функции LazyInitialize или это просто пережитки предыдущих попыток избавиться от состояния гонки?

Упражнение: какие изменения нужно внести (если они вообще требуются) в случае, когда глобальные переменные являются указателями? А если — переменными для чисел с плавающей точкой?

Обновление: посмотрите переписку между пользователями Niall и Anon относительно необходимости семантики захвата (acquire semantics) при первоначальном чтении значений из переменных.

dwUniqueId = InterlockedCompareExchange(&g_dwUniqueId,
                                        g_dwUniqueId+1,
                                        g_dwUniqueId);

Скорее всего, проще будет перечислить то, что в этой функции корректно, нежели перечислять то, что она делает неправильно.

Эм... все слова написаны без ошибок.

Это все.

Дэмиен (Damien) был первым, кто отметил, что автор просто-напросто реализовал еще один вариант функции InterlockedIncrement. Неудовлетворительно.

Как мы видели ранее, алгоритм для выполнения сложных вычислений с использованием interlocked-функций содержит следующие стадии: захват (capture), вычисление (compute), сравнение-обмен (compare-exchange), повтор попытки (retry). Но вышеприведенный код ничего такого не делает.

Без захвата этих значений вышеприведенный код подвержен проблемам, когда два потока в одно и то же время изменяют значение g_dwUniqueId. Это означает, что шаг вычисления может потерпеть неудачу из-за несвоевременного считывания значения g_dwUniqueId, что приведет к тому, что значение, передаваемое в функцию InterlockedCompareExchange, станет неопределенным.

Итак, они правильно написали наименование функции InterlockedCompareExchange. Но потом они забыли реализовать шаг повторения операции, в том случае, когда шаг сравнения-обмена завершился неудачей, что означает, что они просто-напросто продолжают использовать то значение g_dwUniqueId, которое находилось в этой переменной в момент вызова InterlockedCompareExchange и может быть как корректным, так и некорректным. Если это значение было увеличено на единицу другим потоком, то оба этих потока будут использовать одно и то же «уникальное» значение.

Джошуа (Joshua) отмечает, что настройки оптимизации компилятора могут не позволить операции захвата выполнить действительный захват. Однако я бы предпочел поставить ключевое слово «volatile» перед переменной g_dwUniqueId, нежели перед переменной scv, поскольку объект, помеченный ключевым словом volatile, является глобальной переменной, а не локальной. Пометка локальной переменной ключевым словом volatile заставляет выполнять все запросы к локальной переменной так, как указано в коде, но компилятор по-прежнему может оптимизировать операции доступа к переменной g_dwUniqueId. (К примеру, он может использовать значение переменной, полученное во время ее предыдущего считывания в функции).

И примите во внимание предупреждение Лео Дэвидсона (Leo Davidson): эта серия статей предназначена для того, чтобы заглянуть за кулисы и узнать, как там все устроено, а не для того, чтобы дать готовые инструкции и примеры для использования в реальных проектах. Нам придется разобрать несколько тостеров, чтобы узнать, как они работают. Но в реальных проектах, когда это возможно, лучше используйте код, написанный людьми, которые умнее вас.

// предположим, что все допустимые значения переменных a и b удовлетворяют условиям:
// a ≥ 0 и b ≥ a. Таким образом, -1 не является допустимым значением
// и мы будем использовать его для того, чтобы обозначить,
// что эта переменная еще не проинициализирована.
int a = -1, b = -1;

void LazyInitialize()
{
  if (a != -1) return; // уже проинициализировано

  a = calculate_nominal_a();
  b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  a = max(0, a);
  b = max(a, b);
}

Этот код отлично работает в однопоточной программе, но если программа будет многопоточной, может возникнуть такая ситуация, когда два потока попытаются одновременно проинициализировать переменные, что приведет к состоянию гонки (race conditions). В результате один из потоков будет использовать значения переменных до того, как они будут проинициализированы:

Обратите внимание, что в случае, когда Поток 1 первым получил управление, то после операции записи значения в переменную a второй поток будет считать, что все уже проинициализировано и может сделать попытку использования неинициализированной переменной b.

«Ага», — скажете вы, — «это несложно исправить. Я просто буду использовать переменную b вместо a для того, чтобы обозначить, что инициализация уже завершена».

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано (проверяем b, а не a)

  a = calculate_nominal_a();
  b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  a = max(0, a);
  b = max(a, b);
}

Это все равно не исключает состояния гонки:

«И это я могу исправить. Я просто посчитаю значения a и b и сохраню их в локальных переменных, а глобальные переменные буду обновлять только после того, как будут посчитаны окончательные значения. В этом случае второй поток не увидит частично вычисленные значения».

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано

  // производим все вычисления и сохраняем их сначала в локальных переменных
  int temp_a = calculate_nominal_a();
  int temp_b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  temp_a = max(0, temp_a);
  temp_b = max(temp_a, temp_b);

  // делаем временные значения постоянными
  a = temp_a;
  b = temp_b;
}

Почти правильно, но все равно возникает состояние гонки:

Нет никаких гарантий того, что результат операции присвоения b = 2 станет видимым для остальных процессоров строго после операции присвоения a = 2. Даже несмотря на то, что операции сохранения значений инициируются в нужном нам порядке, контроллер памяти может выполнить эти операции в обратном порядке, что приведет к тому, что Поток 2 увидит значения a = -1 и b = 2.

Для того чтобы такого не происходило, запись в переменную b должна производиться с семантикой освобождения (Release semantics), требующей, чтобы все предыдущие операции записи в память завершились прежде, чем результат операции записи значения в переменную b станет виден другим процессорам.

void LazyInitialize()
{
  if (b != -1) return; // уже проинициализировано

  // производим все вычисления и сохраняем их сначала в локальных переменных
  int temp_a = calculate_nominal_a();
  int temp_b = calculate_nominal_b();

  // Приведение значений переменных в соответствие с нашими ограничениями.
  temp_a = max(0, temp_a);
  temp_b = max(temp_a, temp_b);

  // делаем временные значения постоянными
  a = temp_a;
  // поскольку мы используем переменную b в качестве индикатора
  // завершения инициализации, мы должны присваивать ей значение в последнюю очередь
  // и использовать при этом семантику освобождения.
  InterlockedCompareExchangeRelease(
        reinterpret_cast<LONG*>&b, temp_b, -1);
}

Если вы взглянете на окончательный результат, вы заметите, что он является повторным изобретением шаблона singleton-инициализации, который гласит: выполните набор вычислений где-нибудь в сторонке, а затем опубликуйте результат в рамках единственной операции InterlockedCompareExchangeRelease.

Следовательно, общий шаблон будет следующим:

void LazyInitializePattern()
{
  if (глобальная_сигнальная_переменная != маркерное_значение) return;

  ... выполнение вычислений и запись результатов в локальные переменные ...

  глобальная_переменная1 = временная_переменная1;
  глобальная_переменная2 = временная_переменная2;
  ...
  глобальная_переменнаяN = временная_переменнаяN;

  // и в последнюю очередь — публикация сигнальной переменной
  // с использованием семантики освобождения для гарантии того,
  // что значения предыдущих переменных также будут видны
  InterlockedCompareExchangeRelease(
        reinterpret_cast<LONG*>&глобальная_сигнальная_переменная,
        временная_сигнальная_переменная, маркерное_значение);
}

Если это чересчур для вас (и учитывая то, что я в первый раз напортачил с коварной двойной проверкой-блокировкой, это чересчур и для меня), вы можете положиться на команду разработки ядра Windows, поручив ей думать обо всех этих деталях, и вместо написания этого кода вручную использовать готовые функции для однократной инициализации, инкапсулирующие всю эту логику. (Мой приятель Дорон (Doron) некоторое время назад обнародовал информацию об этих функциях однократной инициализации). Четвертая версия .NET Framework содержит соответствующую функциональность в классе Lazy<T>.

Упражнение: какие скрытые предположения были сделаны относительно функций calculate_nominal_a и calculate_nominal_b?

Упражнение: какими будут последствия, если мы будем использовать функцию InterlockedExchange вместо функции InterlockedCompareExchangeRelease?

Упражнение: действительно ли нужны переменные temp_a и temp_b в окончательной версии функции LazyInitialize или это просто пережитки предыдущих попыток избавиться от состояния гонки?

Упражнение: какие изменения нужно внести (если они вообще требуются) в случае, когда глобальные переменные являются указателями? А если — переменными для чисел с плавающей точкой?

Обновление: посмотрите переписку между пользователями Niall и Anon относительно необходимости семантики захвата (acquire semantics) при первоначальном чтении значений из переменных.

dwUniqueId = InterlockedCompareExchange(&g_dwUniqueId,
                                        g_dwUniqueId+1,
                                        g_dwUniqueId);

Скорее всего, проще будет перечислить то, что в этой функции корректно, нежели перечислять то, что она делает неправильно.

Эм... все слова написаны без ошибок.

Это все.

Дэмиен (Damien) был первым, кто отметил, что автор просто-напросто реализовал еще один вариант функции InterlockedIncrement. Неудовлетворительно.

Как мы видели ранее, алгоритм для выполнения сложных вычислений с использованием interlocked-функций содержит следующие стадии: захват (capture), вычисление (compute), сравнение-обмен (compare-exchange), повтор попытки (retry). Но вышеприведенный код ничего такого не делает.

Без захвата этих значений вышеприведенный код подвержен проблемам, когда два потока в одно и то же время изменяют значение g_dwUniqueId. Это означает, что шаг вычисления может потерпеть неудачу из-за несвоевременного считывания значения g_dwUniqueId, что приведет к тому, что значение, передаваемое в функцию InterlockedCompareExchange, станет неопределенным.

Итак, они правильно написали наименование функции InterlockedCompareExchange. Но потом они забыли реализовать шаг повторения операции, в том случае, когда шаг сравнения-обмена завершился неудачей, что означает, что они просто-напросто продолжают использовать то значение g_dwUniqueId, которое находилось в этой переменной в момент вызова InterlockedCompareExchange и может быть как корректным, так и некорректным. Если это значение было увеличено на единицу другим потоком, то оба этих потока будут использовать одно и то же «уникальное» значение.

Джошуа (Joshua) отмечает, что настройки оптимизации компилятора могут не позволить операции захвата выполнить действительный захват. Однако я бы предпочел поставить ключевое слово «volatile» перед переменной g_dwUniqueId, нежели перед переменной scv, поскольку объект, помеченный ключевым словом volatile, является глобальной переменной, а не локальной. Пометка локальной переменной ключевым словом volatile заставляет выполнять все запросы к локальной переменной так, как указано в коде, но компилятор по-прежнему может оптимизировать операции доступа к переменной g_dwUniqueId. (К примеру, он может использовать значение переменной, полученное во время ее предыдущего считывания в функции).

И примите во внимание предупреждение Лео Дэвидсона (Leo Davidson): эта серия статей предназначена для того, чтобы заглянуть за кулисы и узнать, как там все устроено, а не для того, чтобы дать готовые инструкции и примеры для использования в реальных проектах. Нам придется разобрать несколько тостеров, чтобы узнать, как они работают. Но в реальных проектах, когда это возможно, лучше используйте код, написанный людьми, которые умнее вас.

Весьма практичным шаблоном для Interlocked-* функций является ленивая инициализация без блокировок, которая использует InterlockedCompareExchangePointerRelease. Да, наименование у этой функции очень длинное, но, в действительности, каждая часть этого наименования важна.

Widget *g_pwidCached;

Widget *GetSingletonWidget()
{
  Widget *pwid = g_pwidCached;
  if (!pwid) {
    pwid = new(nothrow) Widget();
    if (pwid) {
      Widget *pwidOld = reinterpret_cast<Widget*>
            (InterlockedCompareExchangePointerRelease(
                &reinterpret_cast<PVOID&>(g_pwidCached),
                pwid, NULL));
      if (pwidOld) {
        delete pwid; // проиграл в гонке — теперь уничтожь ненужную копию
        pwid = pwidOld; // используй старый экземпляр
      }
    }
  }
  return pwid;
}

Здесь реализована двойная проверка, но блокировка при этом не используется. Вместо нее во время первого создания объекта мы просто-напросто разрешаем создавать этот объект всем потокам, дошедшим до выполнения этой операции. Если все пять потоков дойдут до этой точки одновременно, то пусть создают пять объектов, мы не будем им мешать. После того, как все они создадут по одному объекту, который, как они считают, единственный, они должны вызвать InterlockedCompareExchangePointerRelease для попытки обновления глобального указателя.

Части наименования функции InterlockedCompareExchangePointerRelease означают примерно следующее:

• Interlocked (блокирующий): операция выполняется атомарно. Это важно для того, чтобы избежать ситуации, когда два потока одновременно обновляют значение g_pwidCached.
• Compare (сравнение): значение g_pwidCached будет сравниваться со значением NULL.
• Exchange (обмен): если значения равны, то значение g_pwidCached будет установлено равным значению pwid. Эта операция, вкупе со сравнением, гарантирует, что значение g_pwidCached будет установлено только одним потоком.
• Pointer (указатель): операции работают с указателями.
• Release (освобождение): операция выполняется с использованием семантики освобождения (release semantics). Это очень важно, поскольку объект pwid, создаваемый нами, должен быть проинициализирован полностью, прежде чем ссылка на него станет доступной другим процессам.

Эта техника приемлема, когда допускается создание объекта из множества потоков (и уничтожение копий в потоках, которые не успели создать первый экземпляр объекта). Если создание объекта требует больших затрат ресурсов или содержит нежелательные побочные эффекты, тогда такой алгоритм неприменим.

Дополнительная информация для ознакомления:

• Вспомогательные функции для создания объектов с однократной инициализацией избавляют от написания всего этого вспомогательного кода. Они работают со всеми видами синхронизаций и барьерами памяти (memory barrier) и поддерживают как алгоритмы, в которых создание экземпляра допускается только один раз, так и алгоритмы, в которых создание экземпляров допускается несколько раз в разных потоках (как в рассмотренном выше примере).
• В статье «Примеры использования ленивой инициализации в .NET» описано то же самое, но с использованием языка C#.

Отлично, а теперь — обещанное интересное упражнение. Здесь описана реально существовавшая проблема, которую я помогал решить, но некоторые ее детали были изменены для того, чтобы пример был более понятным.

У нас есть структура данных, которая управляет группой singleton-объектов. Предположим, что все они являются экземплярами структуры ITEMCONTROLLER и имеют 32-битный ключ-идентификатор. Требуется найти способы модификации этого кода, чтобы сделать его потокобезопасным. Существующий код выглядит примерно так (он представлен в виде псевдокода):

struct ITEMCONTROLLER;
struct SINGLETONINFO {
  DWORD dwId;
  ITEMCONTROLLER *(*pfnCreateController)();
};

class SingletonManager {
public:
  // rgsi — массив, описывающий, как следует создавать объекты, он является статическим
  // csi принимает значения в интервале от 20 до 50.
  SingletonManager(const SINGLETONINFO *rgsi, UINT csi)
                : m_rgsi(rgsi), m_csi(csi),
                  m_rgcs(NULL), m_ccs(0), m_ccsAlloc(0) { }
  ~SingletonManager() { ... }
  ITEMCONTROLLER *Lookup(DWORD dwId);

private:
  struct CREATEDSINGLETON {
    DWORD dwId;
    ITEMCONTROLLER *pic;
  };

private:
  const SINGLETONINFO *m_rgsi;
  int m_csi;

  // Массив, описывающий созданные объекты
  CREATEDSINGLETON *m_rgcs;
  int m_ccs;
};

ITEMCONTROLLER *SingletonManager::Lookup(DWORD dwId)
{
  int i;

  // Проверяем, создан ли уже объект
  for (i = 0; i < m_ccs; i++) {
    if (m_rgcs[i].dwId == dwId)
      return m_rgcs[i].pic;
  }

  // Объект еще не создан — самое время создать его
  ITEMCONTROLLER *pic;
  for (i = 0; i < m_rgsi; i++) {
    if (m_rgsi[i].dwId == dwId) {
      pic = m_rgsi[i].pfnCreateController();
      break;
    }
  }
  if (pic == NULL) return;

  ... если m_rgcs == NULL, тогда нужно выделить под него память и обновить значение m_ccsAlloc
  ... иначе увеличить его размер, выделив под него дополнительную память, и обновить значение m_ccsAlloc

  // добавим созданный объект в наш массив, чтобы в следующий раз мы смогли его найти
  m_rgcs[m_ccs].dwId = dwId;
  m_rgcs[m_ccs].pic = pic;
  m_ccs++;

  return pic;
}

Как видно из этого кода, класс SingletonManager принимает массив структур SINGLETONINFO, каждая из которых содержит идентификатор и функцию, которую нужно вызывать для создания объекта с данным идентификатором. Прежде чем просматривать этот массив мы проверяем, не был ли создан данный объект ранее, и если он был создан, мы просто возвращаем его. В противном случае мы создаем объект (используя функцию pfnCreateController) и добавляем его в наш массив созданных объектов.

Нашим изначальным намерением было создание критической секции вокруг всей функции Lookup, но, возможно, есть какой-то более умный способ? Может, использовать тонкую блокировку чтения/записи (slim reader-writer lock)?

В продолжение темы: несмотря на то, что на платформе Windows обычные версии interlocked-функций предполагают и семантику захвата (acquire semantics), и семантику освобождения (release semantics), в других платформах все может быть иначе. В частности, на платформе XBOX360 обычные версии interlocked-функций не предполагают ни семантику захвата, ни семантику освобождения. Какое поведение реализовано на платформе Windows CE, мне неизвестно.

Дополнения к статье: раньше я знал, но потом забыл о том, что вариант шаблона «Одиночка» (singleton), описанный в этой статье (с использованием InterlockedCompareExchangePointer), не является потокобезопасным на некоторых архитектурах процессоров. Для того чтобы гарантировать, что при использовании косвенного доступа в операции извлечения указателя будет получено новое значение, а не одна из его закэшированных копий, после операции извлечения следует добавить вызов MemoryBarrier().

Widget *GetSingletonWidget()
{
  Widget *pwid = g_pwidCached;
  if (!pwid) {
    ...
  } else {
    // Нужно убедиться, что разыменование pwid будет возвращать новые,
    // а не старые, закэшированные значения.
    MemoryBarrier();
  }
  return pwid;
}

Обсуждение алгоритмов без использования блокировок (возможно, с еще большим количеством ошибок!) будет продолжено в следующий раз.

dwUniqueId = InterlockedCompareExchange(&g_dwUniqueId,
                                        g_dwUniqueId+1,
                                        g_dwUniqueId);

Покритикуйте этот фрагмент кода.

Два котенка шли по улице, и один из них шлепнулся на попу!

Я разработал эту шутку для одной из моих любимых племянниц. Она только начала учиться рассказывать шутки и попросила меня рассказать ей какую-нибудь шутку. Один из основных ключей к успеху в рассказывании шуток — понимание своей аудитории. Вы потеряете внимание трехлетнего малыша, если шутка будет длинной. Тонкий юмор и чересчур умные шутки тоже не сработают. Шутка должна быть короткой и понятной. Моя племянница считает котят милыми, а когда кто-то падает на попу, это смешно, поэтому я подумал, дай-ка я объединю эти два момента.

Когда я рассказал ей эту шутку, она упала на пол и зашлась в безудержном смехе. Я нашел шутку-победителя.