Еще один вектор где лежат одни дырки?

А как менеджерить этот вектор адресов дырок? И как его блокировать? Он ведь тоже будет играть по правилам
твоей мультипоточки и ему точно также нужны будут мутексы или критические секции.

Никто на это не ответит. Программирование - это практическая наука. А моделируемый объект (программа)
настолько сложен что мы не в состоянии создать формулу времени отклика. Напиши макет кода. Запускай.
И смотри как он работает.

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

Тоесть смысл моего поста в том что мы не можем предложить улучшение к пустоте. Нам нужен объект.

Кстати у меня к тебе настойчивая модераторская просьба - огласить полное ТЗ. Я понимаю
что для тебя это игровая задача и ты по ходу придумываешь брейнштомом всякие костыли
и подпорки в виде массивов индексов. Но мы просто топчемся на месте.

Это-же не все. Дальше ты писал еще про "адреса дырок". Что с ними делать? Ты их уже отменяешь?

И еще надо-бы знать сколько будет потоков. Если их будет 100500 - тогда наверное лучше их ставить
в некую очердь команд. И надо знать (примерно) характер и род доступа к массиву. Если он - когерентный
- то мы можем шибко соптимизировать на близких адресах хотя-бы в пределах кеш-линий или страниц.
Если между потоками не нужен жесткий ордеринг команд - то мы можем переупорядочить поток команд
таким образом чтобы мы больше писали в кеш-линию и страницу чем рандомно. Так работали старые жесткие
диски (NCQ/TCQ). И вроде-бы никто не замечал логических ошибок чтения записи. Всё было прозрачно.
И вообще чем больше твой массив - тем больше надо думать об эффекте L2/L3.