Сходство потоков OpenMP со статическими переменными

Question

У меня есть класс C ++ C, который содержит некоторый код, включая статическую переменную, предназначенную только для чтения, и, возможно, статическую функцию constexpr. Например:

template<std::size_t T>
class C {
   public:
     //some functions
     void func1();
     void func2()
     static constexpr std::size_t sfunc1(){ return T; }


   private:
     std::size_t var1;
     std::array<std::size_t,10000> array1;
     static int svar1;

}

Идея состоит в том, чтобы использовать механизмы сходства потоков в openMP 4.5 для управления сокетом (архитектура NUMA), где выполняются различные экземпляры этого класса (и, следовательно, также помещать его в область памяти рядом с сокетом, чтобы избежать использования межсоединения). между узлами NUMA). Насколько я понимаю, поскольку этот код содержит статическую переменную, он эффективно распределяется между всеми экземплярами класса, поэтому я не буду контролировать область памяти, в которой будет размещена статическая переменная, при создании потока. Это правильно? Но я предполагаю, что другие нестатические переменные будут расположены в местах памяти рядом с используемым сокетом? Спасибо

Answer 1

Вы должны предположить, что стек потока, привязанный к потоку malloc и локальное хранилище потока будут выделять "локальную" память потока - поэтому любые автоматические или новые переменные должны быть оптимизированы по крайней мере в том потоке, в котором они были созданы, хотя я не знаю, какие компиляторы поддерживают такую ​​модель распределения; но, как вы говорите, статические неконстантные данные могут существовать только в одном месте. Я предполагаю, что если компилятор распознает константные сегменты или построенные константные сегменты, то после построения они могут быть продублированы для каждой зоны и затем сопоставлены с одним и тем же логическим адресом? Опять же, не знаю, делают ли это компиляторы автоматически.

Неконстантная статика будет хлопотной. Предположительно, эти статики помогают выполнять какую-то синхронизацию потоков. Если они содержат флаги, которые часто читаются и пишутся редко, то для лучшей производительности для автора может быть лучше записать количество зарегистрированных копий (по одной на зону), и каждый поток использует локальный указатель потока на соответствующую копию зоны, чем половина (или 3/4) читателей всегда медленные. Конечно, это перестает быть простой атомарной записью, и один мьютекс просто возвращает вас туда, откуда вы начали. Я подозреваю, что это кодовая земля.

Простой случай, который не следует забывать: если объекты передаются между потоками, то потенциально поток может обращаться к нелокальному объекту.