Всем привет!

GCC 4+, *nix, но должно стабильно работать и под виндой.

Есть ассоциативный массив:

typedef std::map< int, boost::shared_ptr<class Bar>, std::greater<int> > my_map_t;
my_map_t my_map;

На самом деле, возможно, здесь больше подойдёт другой контейнер.
Инты в массиве могут идти с пропусками. Разница двух значений ключей прямо пропорциональна времени между их добавлением. (Но ключ -- не UNIX epoch time.)

Содержимое массива не изменяется. Кроме двух случаев:

1) Время от времени в массив, всегда в конец, добавляются новые объекты.

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

Массивом пользуются некоторое количество "читателей":

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

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

my_map_t::const_iterator it1 = my_map.find(key);
my_map_t::const_iterator it2 = my_map.begin();

Основной вопрос:

Очень хочется (из-за производительности) сделать чтобы процесс чтения не заботился о синхронизации с процессом сборки мусора. Можно конечно играть ограничением на минимальный ключ для чтения — сделав его, например, в два раза ближе к нам чем максимальный ключ на удаление (минимально допустимый период читаемости будет секунд тридцать). Но это (1) выглядит как-то подозрительно и (2) есть подозрение, что будет накапливаться слишком много объектов и GC будет недостаточно агрессивен...

Что посоветуете?

Заранее спасибо,
Tuo_Bellas.