Поточно-безопасная инициализация локальных статических константных объектов функции

Я не стандартист ...

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

Ленивая мода имеет смысл только в том случае, если вы используете это значение из другого «глобального».

С другой стороны, еще один метод, который я видел, заключался в использовании какой-то координации:

• 'Singleton' для регистрации своего метода инициализации в объекте 'GlobalInitializer' во время загрузки библиотеки.
• GlobalInitializer будет вызываться в main перед запуском любого потока

хотя, возможно, я неточно это описываю.

Вкратце, я думаю, что:

• Инициализация объекта является потокобезопасной, предполагая, что some_mutex полностью сконструирован при вводе create_const_thingy.

• Не гарантируется, что инициализация ссылки на объект внутри use_const_thingy будет потокобезопасной; он может (как вы говорите) подвергаться многократной инициализации (что менее проблематично), но он также может быть подвержен разрыву слов, что может привести к неопределенному поведению.

[Я предполагаю, что ссылка C ++ реализована как ссылка на фактический объект с использованием значения указателя, которое теоретически может быть прочитано при частичной записи].

Итак, чтобы попытаться ответить на ваш вопрос:

1. Достаточно безопасно на практике: очень вероятно, но в конечном итоге зависит от размера указателя, архитектуры процессора и кода, сгенерированного компилятором. Суть здесь, вероятно, заключается в том, является ли запись / чтение размером с указатель атомарной или нет.

2. Безопасно по правилу: ну, извините, в C ++ 98 таких правил нет (но вы это уже знали).

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

Я запрограммировал достаточно межпроцессных сокетов, чтобы мне снились кошмары. Чтобы сделать что-либо поточно-ориентированным на ЦП с ОЗУ DDR, вы должны выровнять структуру данных по строкам кэша и упаковать все ваши глобальные переменные непрерывно в как можно меньше строк кеша.

Проблема с невыровненными межпроцессными данными и слабо упакованными глобальными объектами заключается в том, что они вызывают наложение из-за промахов кеша. В процессорах, использующих DDR RAM, есть (обычно) набор из 64-байтовых строк кэша. Когда вы загружаете строку кэша, DDR RAM автоматически загружает еще несколько строк кэша, но первая строка кэша всегда самая горячая. Что происходит с прерываниями, которые происходят на высоких скоростях, так это то, что страница кеша будет действовать как фильтр нижних частот, как и в аналоговых сигналах, и будет отфильтровывать данные прерывания, что приводит к ПОЛНОСТЬЮ сбивающим с толку ошибкам, если вы не в курсе, что происходит. То же самое и с глобальными переменными, которые не упакованы плотно; если он занимает несколько строк кэша, он выйдет из синхронизации, если вы не сделаете снимок критических межпроцессных переменных и не передадите их в стек и регистры, чтобы обеспечить правильную синхронизацию данных.

Раздел .bss (то есть, где хранятся глобальные переменные, будет инициализирован всеми нулями, но компилятор не будет выравнивать данные за вас по строкам кеша, вам придется сделать это самостоятельно, что также может быть хорошим местом для используйте C ++ Construct in Place. Чтобы изучить математику, лежащую в основе самый быстрый способ выровнять указатели прочтите в этой статье; Я пытаюсь понять, придумал ли я этот трюк. Вот как будет выглядеть код:

inline char* AlignCacheLine (char* buffer) {
  uintptr_t offset = ((~reinterpret_cast<uintptr_t> (buffer)) + 1) & (63);
  return buffer + offset;
}

char SomeTypeInit (char* buffer, int param_1, int param_2, int param_3) {
  SomeType type = SomeType<AlignCacheLine (buffer)> (1, 2, 3);
  return 0xff;
}

const SomeType* create_const_thingy () {
  static char interprocess_socket[sizeof (SomeType) + 63],
              dead_byte = SomeTypeInit (interprocess_socket, 1, 2, 3);
  return reinterpret_cast<SomeType*> (AlignCacheLine (interprocess_socket));
}

По моему опыту, вам придется использовать указатель, а не ссылку.

Просто вызовите функцию перед тем, как начать создавать потоки, тем самым гарантируя ссылку и объект. В качестве альтернативы, не используйте такой по-настоящему ужасный шаблон проектирования. Я имею в виду, зачем вообще статическая ссылка на статический объект? Зачем вообще статические объекты? В этом нет никакой пользы. Синглтоны - ужасная идея.

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

static My_object My_object_instance()
{
    static My_object  object;
    return object;
}

// Ensures that the instance is created before main starts and creates any threads
// thereby guaranteeing serialization of static instance creation.
__attribute__((constructor))
void construct_my_object()
{
    My_object_instance();
}