tr1:: хеш для повышения:: поток:: идентификатор?

Почему вы хотите хранить их в наборе. Если вы не делаете что-то необычное, будет небольшое количество потоков. Затраты на поддержание набора, вероятно, выше, чем просто поместить их в вектор и выполнить линейный поиск.

Если поиск будет происходить чаще, чем добавление и удаление, вы можете просто использовать отсортированный вектор. Для boost :: thread :: id определен оператор <, так что вы можете отсортировать вектор (или вставить в правильное место) после каждого добавления или удаления и использовать lower_bound () для создания двоичного файла. поиск. Это та же сложность, что и при поиске по набору, и для небольших объемов данных они должны быть менее затратными.

Если вам все еще нужно это сделать, как насчет того, чтобы обрабатывать его как байты sizeof (boost :: thread: id) и работать с ними.

В этом примере предполагается, что размер boost :: thread :: id кратен размеру int и что нет упаковки и виртуальных функций. Если это не так, его нужно будет изменить или он не будет работать вообще.

РЕДАКТИРОВАТЬ: Я посмотрел на класс boost :: thread :: id , и он имеет boost :: shared_pointer <> как член, поэтому приведенный ниже код ужасно нарушен. Я думаю, что единственное решение состоит в том, чтобы авторы boost :: thread добавили хеш-функцию. Я оставляю пример на всякий случай, если он полезен в каком-то другом контексте.

boost::thread::id id;
unsigned* data;
// The next line doesn't do anything useful in this case.
data = reinterpret_cast<unsigned *>(&id);
unsigned hash = 0;

for (unsigned int i = 0; i < sizeof(boost::thread::id)/4; i++)
  hash ^= data[i];

Возникает очевидный вопрос: зачем на самом деле использовать хеш?

Я понимаю проблему с map / , установленным для критической производительности кода, действительно, эти контейнеры не очень удобны для кеширования, потому что элементы могут быть размещены в очень разных местах памяти.

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

Сортированные векторы / двухсторонние объекты гораздо более удобны для кеширования, однако они страдают от сложности O (N) при вставке / стирании из-за задействованного копирования. Как только вы дойдете до пары сотен потоков (кстати, такого количества никогда не видел), это может повредить.

Однако существует структура данных, которая пытается связать преимущества карт и отсортированных векторов: B + Tree .

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

Чтобы повысить производительность, вы можете:

• Линейно связать листья: то есть корень кэширует указатель на первый и последний лист, а листья сами связаны между собой, так что линейное перемещение полностью обходит внутренние узлы.
• Кэшировать последний лист, к которому был осуществлен доступ, в корне, в конце концов, вполне вероятно, что это будет и следующий лист, к которому был осуществлен доступ.

Асимптотические характеристики такие же, как и для карты, потому что она реализована как сбалансированное двоичное дерево, но поскольку значения упакованы в группы, ваш код может стать быстрее с помощью константы.

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

вы можете создать класс, который выполняет сопоставление между thread :: id и чем-то (например, целыми числами), который вы можете использовать в качестве хэша. единственный недостаток состоит в том, что вы должны убедиться, что в системе есть только один экземпляр объекта сопоставления.