Привет.
Подскажите, какую структуру данных лучше взять для достаточно типичной задачи: есть множество коллбэков, необходимо удалять/добавлять новые (write доступ), вызывать их в цикле (read доступ), всё это в многопотоке и с условием, что коллбэк внутри себя может стриггерить удаление/добавление другого коллбэка. Хранятся они по уникальным ключам, удаляются по ним же.

Пока что в голову лезет достаточно жуткое решение с тремя пулами (current, items_to_add, items_to_remove) под тремя мьютексами и нетривиальной логикой. Но я уверен, что есть какие-то общепринятые практики

Время прихода клиента моделируется по экспоненциальному распределению со средним временем tсреднее.прих. для интервалов между поступлениями.

tсреднее.прих., мин = 6

Если я правильно понял, то интервал между поступлениями это 1/6 ?

не, смотри..

lock(mutex);
for (const auto& [id, callback] : m_map) {
  callback();
}
unlock(mutex)

и теперь внезапно внутри callback у нас написано: m_map.clear() или m_map.erase(123) (под мьютексом, конечно). Это либо дедлок на одном потоке, либо инвалидация итераторов, либо висячая ссылка, либо всё вместе :)

Мне кажется эта проблема обычно решается копированием нужной цепочки под локом и отпусканием лока. Правда я не пониял, почему итерация идет по всей мапе. Я бы предположил, что в мапе по событию мы находим цепочку коллбэков, копируем ее, отпускаем лок и начинаем их исполнять.

Мне кажется эта проблема обычно решается копированием нужной цепочки под локом и отпусканием лока. Правда я не пониял, почему итерация идет по всей мапе. Я бы предположил, что в мапе по событию мы находим цепочку коллбэков, копируем ее, отпускаем лок и начинаем их исполнять.

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

Лок фри тоже не бесплатный. Там много проблем с управлением временем жизни объектов. Простое с точки зрения пользователя решение - это использовать std::atomic<shared_ptr>. Есть варианты с очередями на удаление и амортизацией.

Привет.
Подскажите, какую структуру данных лучше взять для достаточно типичной задачи: есть множество коллбэков, необходимо удалять/добавлять новые (write доступ), вызывать их в цикле (read доступ), всё это в многопотоке и с условием, что коллбэк внутри себя может стриггерить удаление/добавление другого коллбэка. Хранятся они по уникальным ключам, удаляются по ним же.

Пока что в голову лезет достаточно жуткое решение с тремя пулами (current, items_to_add, items_to_remove) под тремя мьютексами и нетривиальной логикой. Но я уверен, что есть какие-то общепринятые практики

Коллбеки — простые функции? Помещаются в указатель?

конечно же нет

Твоё „множество коллбеков“ владеет добавляемыми в него коллбеками?

Тогда локальная арена и вектор атомарных указателей в арену.