Как устроена работа thread_local переменных: разбираемся и добавляем поддержку в учебную ОС

Эта статья написана по мотивам моей курсовой работы, основной смысл которой описан здесь. В процессе работы над ней мне понадобилось добавить в учебной ОС, над которой я работал, поддержку thread_local переменных, о чём я и хочу здесь рассказать в надежде что кому-то это окажется полезно.

Здесь рассмотрен совсем простой случай: поддержки динамической загрузки других бинарников не будет, а способ реализации рассмотрен только один.

Код расположен в двух репозиториях.

Что такое thread_local переменные?

Язык C++ позволяет объявлять глобальные переменные thread_local. Переменная, объявленная таким образом, будет разной в разных потоках программы: разные потоки могут её использовать, не используя никакой синхронизации, и каждого из них будет быть своя копия этой переменной.

Как они работают?

Давайте напишем какой-нибудь код, который что-то делает с thread_local переменной и посмотрим, в какой ассемблер он компилируется. Также посмотрим, во что превращается такой же код, но с обычной переменной, а не thread_local:

extern "C" { // чтобы имя функции в ассемблерном коде было понятным thread_local int value = 5; void fn() {     value++; } }

превращается в

fn:         addl    $1, %fs:value@tpoff         ret value:         .long   5

Если убрать thread_local, то будет:

fn:                                     # @fn         addl    $1, value(%rip)         retq value:         .long   5                               # 0x5

Итак, что мы видим? Переменная объявляется в ассемблерном коде (забегая вперёд, скажу, что в бинарнике (ELF-файле) эта переменная будет обявляться в сегменте .data (или .tdata)). Если thread_local нет, то обращение к переменной происходит просто по её адресу в памяти. Если же переменная thread_local, то происходит обращение по какому-то адресу %fs:value. Эта запись означает обращение по адресу (%fs + value). %fs — это segment register. В данном случае достаточно знать, что это регистр, который используется только для доступа к thread local storage — данным конкретного потока.

Следовательно, чтобы поток имел доступ к своему thread local storage (TLS), при его запуске в регистр %fs необходимо записать указатель на конец участка памяти, выделенного под TLS. Осталось разобраться, как в этот регистр что-то записать, как понять, какой должен быть размер TLS и как его инициализировать.

Как что-то записать в сегментные регистры

Всего есть 6 сегментных регистров: %cs, %ds, %ss, %es, %gs и собственно интересующий нас %fs. Поскольку изначально эти регистры задумывались для настройки виртуальной памяти операционной системой, по умолчанию в эти регистры писать может только операционная система (в реальности в настоящее время виртуальная память настраивается с помощью таблиц страниц, и первые 4 перечисленные регистра не используются). Поскольку делать системный вызов просто для того, чтобы что-то записать в регистр довольно неэффективно, то в современных процессорах есть специальные инструкции для этого: readfsbase, writefsbase, readgsbase и writegsbase. Однако использовать их просто так невозможно: дело в том, что некоторые ядра ОС полагаются на то, что пользовательские программы не могут изменять регистры %fs и %gs, поэтому для того, чтобы процессор позволил выполнить такую инструкцию, ядро ОС должно это явно разрешить, выставив флаг в регистре %cr4.

Итак, есть два варианта, как можно писать в регистр %fs для настройки TLS:

• Добавить системные вызовы для чтений и записи регистров %fs и %gs. Ядро ОС может писать в них просто инструкцией mov. Способ не эффективен по времени, так как системный вызов делать долго, зато будет работать на всех процессорах.

• Разрешить инструкции readfsbase, writefsbase, readgsbase и writegsbase и их использовать. Эти инструкции есть только на некоторых процессорах, но меня это не волнует, так как данная учебная ОС запускается через qemu без аппаратной виртуализации, и можно выбрать процессор с поддержкой этих инструкций.

Я выбрал второй вариант, поэтому сначала надо, чтобы ядро ОС при запуске разрешило нужные инструкции. Для этого заменяем

mov $0x6b0, %eax mov %eax, %cr4

на

mov $0x106b0, %eax mov %eax, %cr4

Выделяем память для TLS и инициализируем её

Теперь нам надо как-то понять, какой размер должен быть у TLS и что там должно быть записано.

Обычные глобальные переменные размещаются в ELF-файле в сегментах .data и .bss. В .data попадают инициализированные глобальные переменные, а в .bss попадают неинициализированные, то есть те, в которых нулевые значения. В заголовках сегментов .data и .bss указывается, какой у них размер и по какому адресу в виртуальном адресном пространстве они должны быть загружены. Заголовок .data также содержит указатель на место в ELF файле, где находятся соответствующие данные.

Соответственно, когда исполняемый файл запускается, необходимо:

1. Прочитать заголовок сегмента .data

2. Выделить участок памяти по указанному в заголовку адресу и указанному в заголовке размеру

3. Скопировать в этот участок памяти данные из .data сегмента ELF файла

4. Сделать шаги 1 и 2 для сегмента .bss, но вместо шага 3 занулить всю выделенную память.

5. По-хорошему, в случае с C++ до вызова функции main ещё и должен произойти вызов конструкторов глобальных объектов.

С thread local storage всё устроено довольно похоже. Инициализированные и неинициализированные переменные в ELF-файле находятся в сегментах .tdata и .tbss, соответственно. При запуске потока необходимо выделить память для TLS размера сегментов .tdata и .tbss, инициализировать эту память и записать адрес её конца в регистр %fs. В случае с С++ ещё надо позвать конструкторы thread_local объектов, а при завершении потока надо позвать деструкторы.

Посмотрим на код. Объявляем функции для записи и чтения регистров %fs, %gs.

asm(     ".global rdfsbase\n"     "rdfsbase:\n"     "   rdfsbase    %rax\n"     "   ret\n" );  asm(     ".global rdgsbase\n"     "rdgsbase:\n"     "   rdgsbase    %rax\n"     "   ret\n" );  asm(     ".global wrfsbase\n"     "wrfsbase:\n"     "   wrfsbase    %rdi\n"     "   ret\n" );  asm(     ".global wrgsbase\n"     "wrgsbase:\n"     "   wrgsbase    %rdi\n"     "   ret\n" );

Собственно подготовка thread local storage:

// в tbss и tdata записаны заголовки сегментов .tdata, .tbss из ELF  // файла. Перед вызовом этой функции должна быть вызвана функция чтения ELF файла  void prepare_thread_local() {     thread_local_size = tbss.sh_size + tdata.sh_size;     if (thread_local_size == 0) {         return ; // ничего делать не нужно     }     uint64_t alignment = tdata.sh_addralign;     if (tbss.sh_addralign > alignment) {         alignment = tbss.sh_addralign;     } // c alignment мог немного напутать, но на моих тестах всё работает     thread_local_size = alignup(thread_local_size, alignment);     // выделяем память     auto addr = (char *)malloc(thread_local_size + sizeof(long) + alignment);     // здесь может в зависимости от реализации malloc можеть быть нужна      // проверка на выровненность адреса     // записываем конец памяти в %fs     wrfsbase((uint64_t)(addr + thread_local_size));     // по соглашению с компилятором, в конце TLS должен быть записан указатель     // на него самого для того, чтобы прочитать значение %fs     *(long *)(addr + thread_local_size) = (addr + thread_local_size);      // now we need to initialize memory     int fd = open(ELF_NAME, 0);     // инициализируем иницаилизированные переменные данными из .tdata     pread(fd, addr, tdata.sh_size, tdata.sh_offset);     close(fd);     // обнуляем данные из .tbss     memset(addr + tdata.sh_size, 0, tbss.sh_size); }

В конце работы потока надо освободить выделенное хранилище:

void clean_up_thread_local() {     if (thread_local_size == 0) {         return;     }     free((void *)(rdfsbase() - thread_local_size)); }

Первую функцию надо запустить в начале работы потока, вторую — в конце:

class ThreadLocalHolder { public:     ThreadLocalHolder(thread_entry_arg* arg) {         prepare_thread_local(); // готовим TLS. Чтение ELF файла к этому моменту                                 // уже произошло, оно происходит при запуске процесса         ptr = arg;     }      ~ThreadLocalHolder() {         run_thread_atexit(); // эта функция запускает все задачи, которые                              // должны выполниться в конце работы потока, то есть деструкторы         clean_up_thread_local();         delete ptr;         syscall(Syscall::SYS_THREAD_LEAVE);     } private:     thread_entry_arg* ptr; };  // эта функция вызывается ядром при запуске нового потока.  void thread_func(thread_entry_arg* arg) {     ThreadLocalHolder holder(arg); // вызывается конструктор     try {         arg->f(arg->ptr); // вызываем функцию, переданную при создании потока с аргументом     } catch (...) {         printf("thread leaving due to exception of type %s\n", __cxa_last_exception_name());     }     // вызывается деструктор }

Посмотрим, как происходит вызов конструкторов и деструкторов thread local объектов. Для этого посмотрим на этот код и во что он компилируется.

Если мы заведём thread local переменную, имеющую тип, требующий вызова конструктора и деструктора, то компилятор сгенерирует функцию __tls_init, которая, если вызвана в потоке в первый раз, вызывает конструктор этого объекта и вызывает функцию __cxa_thread_atexit, передавая ей деструктор и объект. __cxa_thread_atexit добавит вызов деструктора в список дел, которые должны быть сделаны перед окончанием работы потока. Функция __tls_init будет вызываться при первом обращении к объекту, требующему инициализации. Чтобы всё коректно работало, нам надо реализовать функцию __cxa_thread_atexit.

Заключение

Вроде вот и всё. Вопросы?