могут быть добавлены/удалены динамически?
Считаем, что thread-local использовать возможности нет, но affinity выставлена корректно.
В случае добавления CPU вижу 2 варианта:
- динамически ресайзить условный vector<shared_ptr<Data>> [общая блокировка на каждую операцию]
- использовать в качестве индекса CpuIdx % PerCpuCount и преаллоцированный вектор vector<pair<Data, Mutex>>
А что делать при удалении - вообще непонятно...
@feedable, просьба не отвечать. Твой флуд мне неинтересен.
А где есть такая фича?
у тебя ж уже есть cpuid, это буквально тлс
Можно страницами выделять ядра
Так что да, преаллокация в большой массив фиксированного размера, если ты работаешь на системах с виртуальной памятью, синхронизацией займётся ос, когда потребуется новая страничка, однако уже выделенные освободить не получится
Это так себе решение. Машина теоретически поддерживает до 2560 CPU. В жизни маловероятно, но 256...512 - реально Выделять столько изначально - явно перебор
Так ты выделяешь - не выделяешь
Я вроде понял идею, но она не работает, если помимо аллокации нужно еще какую-то инициализацию выполнить)
даже если ты все разом выделишь то у тебя выйдет 20кБ
С какого потолка число взято?
по поинтеру на тлс под каждое ядро
Ну типа, то чего ты боишься на самом деле, это реаллокации, если твой массив не меняет адрес, то все в порядке
если мы боимся локов, то подходят ли классические локфри заморочки? если не боимся, то чего мы реально боимся? какие у юзерспейс программы могут быть обязательства в случае хотплага CPU? мы вообще в юзерспейсе?))
А какую вы задачу решаете?
мы вообще в юзерспейсе Нет
это конечно рофлс, но лучше использовать в таком юзкейсе контейнеры и оркестратор. Больше цп? - больше контейнеров, меньше цп? - убиваем контейнеры
Да второй вариант + хранить свободные id массив массивов. При удалении мьютекс добавлено в список свободный id, при создании мьютекс на новый id. Количество id = количество ядер.
Обсуждают сегодня