Каким образом схема именования переносимого механизма хранения, специфичного для потока, генерирует относительные уникальные идентификаторы потока?
Механизм ссылки / идентификации хранилища, зависящий от переносимого потока, примером которого является boost / thread / tss.hpp, необходим способ генерирования уникальных ключей для себя. Этот ключ является уникальным в области видимости потока и впоследствии используется для извлечения объекта, на который он ссылается. Этот механизм используется в коде, написанном в потоке-нейтральной манере.
Так как boost является переносимым примером этой концепции, как конкретно работает такой механизм?
1 ответ
Повышающий поток переносим в библиотеку потоков pthread (для unix) и низкоуровневые API-интерфейсы Windows win32. Библиотека позволяет создать ссылку, уникальную для каждого потока выполнения. Глобальный C API errno
представлен в качестве примера этой концепции в документации Boost.
Ignore If you Want - это всего лишь трассировка по исходному коду, нахождение интересующей функции
Суть дела начинается в [boost]/boost/thread/tss.hpp
с get
функция thread_specific_ptr
и reset
функция - т.е. приобретение и уничтожение, соответственно, объекта, на который делается ссылка. Примечание: объект данных не помещается в ссылку thread_specific_ptr
это ctor, или уничтожен dtor. Вызов функции get и reset set_tss_data
а также get_tss_data
, Сосредоточив внимание только на настройке аспекта функциональности, важном вызове функции, get_current_thread_data
, косвенно через файл cpp [boost]/libs/thread/src/[libname]/thread.cpp
через цепочку вызовов функций. В get_current_thread_data
есть вызов функции create_current_thread_tls_key
и это функция, которая создаст уникальный идентификатор для thread_specific_ptr
объект.
create_current_thread_tls_key
звонки TlsAlloc()
на win32 ( ссылка) и pthread_key_create
для pthread ( ссылка). Эти вызовы гарантируют, что после инициализации ptr, ptr получает уникальный идентификатор, используемый специфичным для API способом для извлечения данных объекта. Специфичный API потоков использует идентификатор потока (специфичный для контекста и разрешаемый самой библиотекой) и идентификатор объекта для возврата объекта, специфичного для контекста определенного потока.