Счетчик ссылок без блокировок и интеллектуальные указатели C ++

addr aIandF(addr r1) {
  addr tmp;
  int c;
  do {
    do {
      // r1 holds the address of the address
      // of the refcount
      tmp = *r1;       // grab the address of the refcount
      if (!tmp) break; // if it's null, bail

      // read current refcount
      // and acquire reservation
      c = lwarx(tmp);

      // now we hold the reservation,
      // check to see if another thread
      // has changed the shared block address
    } while (tmp != *r1); // if so, start over

    // if the store succeeds we know we held
    // the reservation throughout
  } while (tmp && !stwcx(tmp, c+1));
  return tmp;
};

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

В статье доктора Доббса описывается операция по освобождению ссылки как первая атомарная замена адреса общего счетчика в исходном объекте общего указателя нулевым указателем, локальным для функции; затем атомарное уменьшение счетчика; затем тестирование, чтобы увидеть, был ли результат декремента нулевым. Этот порядок операций важен: вы говорите: «Адрес совместно используемого объекта может никогда не измениться, и LL / SC может быть успешным - но как это нам поможет, если другой поток тем временем освободил разделяемый объект? " - но этого никогда не произойдет, поскольку объект никогда не будет освобожден без предварительной замены, что дает нам возможность наблюдать за изменением адреса.

aIandF проверяет, является ли адрес счетчика нулевым при входе.

Он может обнаружить, что адрес становится нулевым, если это происходит до lwarx, потому что он явно проверяет это после резервирования.

Если своп в уменьшающемся потоке происходит после lwarx, нас это не волнует: если stwcx в aIandF завершится успешно, мы знаем, что убывающий поток увидит новый счетчик ссылок и не разрушит объект, и мы можем продолжить, зная, что мы потребовали ссылка на него; тогда как, если другому потоку удастся сначала уменьшить счетчик, мы потеряем наше резервирование, сохранение не будет выполнено, и мы обнаружим разрушение объекта на следующей итерации цикла.

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

РЕДАКТИРОВАТЬ: подумав об этом, алгоритм также, по-видимому, делает предположение, что всегда безопасно читать из адреса памяти, который когда-то был действительным (например, без MMU / защиты; или алгоритм сломан) :

if (!tmp) break;

// another thread could, at this point, do its swap, 
// decrement *and* destroy the object tmp points to
// before we get to do anything else

c = lwarx(tmp); 

// if that happened, we'll detect this fact and do nothing with c
// but ONLY if the lwarx doesn't trap 
// (due to the memory tmp points to 
// getting unmapped when the other thread frees the object)