Подсчет ссылок атомарными переменными в C/C++ и GCC

Где-то рядом. В топиках с прикольными картинками, инновационными свистелками и очередными клонами очередных девайсов.

Насчет примеров — самые яркие из них это работа с данными в БД. Положим, в некоторой непродуманной архитектуре есть процесс 1, который периодически чистит таблицу, например вчерашние данные («DELETE FROM mytable WHERE mydate<SYSDATE-1»), а другой процесс 2, оперируя закешированными данными или непосредственно делая предварительную выборку данных захочет поменять какую-то строку, предполагаемую для удаления процессом 1. процесс 2 считывает данные, процесс 1 удаляет данные, процесс 2 пытается изменить удаленную строку. Упс. Это еще не худший вариант, ибо есть deadlock'и

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

Зачем надо ждать? Если число ссылок больше, чем один, значит кто-то захватил объект. Вот когда он освободит, будет проверено, есть ли еще ссылки не объект. Если нет, то объект удаляется.

Именно об этом и говорится в тексте. Если число ссылок больше чем один, значит объект еще пользуется каким-то процессом, мы его удалить не можем и потоку придется ждать его освобождения.
Можно еще, чтобы не ждать, реализовать callback на нулевое число ссылок, хотя в этом случае никто не гарантирует отсутствие дополнительных проблем.

Скорее всего я просто не понял сценарий.

Если кратко, то при наличии структуры объектов, лочить ее mutex'ом всю при операциях над объектами несколькими потоками — слишком накладно и может увеличить простои одного из процессов в бесконечность.
В этом смысле аналогией может быть работа общественной уборной.
Если при каждом заходе в уборную на 10 кабинок будет лочится вся уборная — вырастет огромная очередь.
А уборная должна периодически чиститься. И уборщица не знает заняты ли места в уборной или нет.
Заходящий в уборную должен оповестить других о занятости кабинки. Потому заходя в кабинку сигнализирует об этом (atomic counter). Не исключено, что он может туда зайти и не один, но выйти все равно должны когда-то все из кабинки и разлочить ее. Периодически в уборную заглядывает уборщица. И когда она видит, что все двери разлочены — оставляет знак перед входом об уборке (mutex) и чистит уборную.

жаль что сугубо заточен под задачу где есть поток удалятор, и 1-N поток юзателей

да, можно еще сказать, что наличие объекта определяется единичным счетчиком, а остальные операции — счетчиком большим 1.
Можно еще обобщенно представить это в таком подобии псевдокода (разумеется, в оригинале объект сразу инициализируется в 1, как частный случай реализации):

eraser {
  atomic++;
  updater1 {
    atomic++;
    job();
    atomic--;
  }
  updater2 {
  ...
  }
  atomic--;
}

Может, это натолкнет на мысли об альтернативном использовании. А какая именно схема интересна?

И я не очень понял и как получить (использовать) объект?

Похоже, автор статьи больше «затачивался» в ней на чистом Си, потому и не стал писать примеры C++.

Использование зависит от реализации. В этом смысле, думаю, мысль в правильном направлении — можно сделать шаблон аналогичный смарт поинтерам или даже наследоваться от какого-нибудь из них с перегрузкой для инкремента/декремента атомарного счетчика. Т.е. получается, что итератор будет модифицированным смарт поинтером. Но тут проблема — получается, что локинг будет при каждом обращении к поинтеру, потому iterator->lock()/unlock() вполне вариант. Можно еще как вариант сделать класс сессионности, лочащего и разлочивающего объект в своей зоне видимости.

Но в этом случае нельзя полагаться на то, что объект используется минуту.

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

интересно а как вы ее использовать собрались? Список в самом простом его представлении это структура вида
{
next*
prev*
data
}

когда вы удаляете элемент вам нужно изменить не один а три элемента. next у предыдущего должен указывать на следующий за удаляемым. prev следующего за удаляемым должен указывать на предыдущий перед удаляемым. И только потом уже можно удалять элемент.
Тут есть два вариант, либо лочить всю очередь. Либо, может быть, возможно придумать, как лочить только три объекта удаляемые, и те что слева справа от него. Но это крайне сложно, так как делать это по сути нужно атомарно. Но так же это будет офигенски многопоточная очередь.

Добавлю к предыдущему комментарию, что shared_ptr — не обеспечивает полного thread safety.

Как сказано в документации к последнему Boost 1.50:

Объекты shared_ptr обеспечивают тот же уровень потокобезопасности что и встроенные типы. Экземпляр shared_ptr-а может «считываться» одновременно несколькими потоками (доступ с использованием только константных операций). В различные экземпляры shared_ptr-а может производиться «запись» (доступ с использованием изменяемых операций, таких как оператор= или reset) одновременно несколькими потоками (даже если эти экземпляры — копии и разделяют внутри один и тот же счетчик ссылок).
Любые другие варианты одновременного доступа приводят к непредсказуемому поведению.

В c++0x говорится о том же.

В целом же, основная проблема потокобезопасности shared_ptr в том, что его экземпляр — потокобезопасен, а объект, на который он ссылается — нет.