Имитация разрыва двойника в C#

static double s_x;

Гораздо сложнее продемонстрировать эффект, когда вы используете двойника. ЦП использует специальные инструкции для загрузки и сохранения двойного файла, соответственно FLD и FSTP. С long все намного проще, так как нет единой инструкции, загружающей/сохраняющей 64-битное целое число в 32-битном режиме. Чтобы наблюдать это, вам нужно, чтобы адрес переменной был смещен, чтобы он пересекал границу строки кэша процессора.

Это никогда не произойдет с используемым вами объявлением, JIT-компилятор гарантирует, что двойное значение правильно выровнено, сохранено по адресу, кратному 8. Вы можете сохранить его в поле класса, распределитель GC только выравнивает до 4 в 32-битный режим. Но это дерьмовая съемка.

Лучший способ сделать это — намеренно сместить двойник с помощью указателя. Поместите unsafe перед классом Program и сделайте его похожим на это:

    static double* s_x;

    static void Main(string[] args) {
        var mem = Marshal.AllocCoTaskMem(100);
        s_x = (double*)((long)(mem) + 28);
        TestTearingDouble();
    }
ThreadA:
            *s_x = ((i & 1) == 0) ? 0.0 : double.MaxValue;
ThreadB:
            double x = *s_x;

Это по-прежнему не гарантирует хорошего смещения (хе-хе), поскольку нет способа точно контролировать, где AllocCoTaskMem() будет выравнивать выделение относительно начала строки кэша процессора. И это зависит от ассоциативности кеша в ядре вашего процессора (у меня Core i5). Придется повозиться со смещением, я получил значение 28 опытным путем. Значение должно делиться на 4, но не на 8, чтобы действительно имитировать поведение кучи сборщика мусора. Продолжайте добавлять 8 к значению, пока вы не получите двойное значение, которое охватит строку кэша и вызовет утверждение.

Чтобы сделать это менее искусственным, вам придется написать программу, которая сохраняет двойное значение в поле класса и заставить сборщик мусора перемещать его в памяти, чтобы он сместился. Довольно сложно придумать пример программы, которая обеспечивает это.

Также обратите внимание, как ваша программа может продемонстрировать проблему, называемую ложным обменом. Закомментируйте вызов метода Start() для потока B и обратите внимание, насколько быстрее работает поток A. Вы видите стоимость процессора, поддерживающего согласованность строки кэша между ядрами процессора. Здесь подразумевается совместное использование, поскольку потоки обращаются к одной и той же переменной. Настоящее ложное совместное использование происходит, когда потоки обращаются к разным переменным, хранящимся в одной и той же строке кэша. В противном случае выравнивание имеет значение, вы можете наблюдать разрыв для двойника только тогда, когда его часть находится в одной строке кэша, а часть - в другой.

Как ни странно, это зависит от вашего процессора. Хотя дубликаты не гарантируют, что они не порвутся, они не будут разрываться на многих современных процессорах. Попробуйте AMD Sempron, если вам нужен разрыв в этой ситуации.

РЕДАКТИРОВАТЬ: Узнал это несколько лет назад на собственном горьком опыте.

Покопавшись, я нашел несколько интересных материалов, касающихся операций с плавающей запятой в архитектурах x86:

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

[...] последующие процессоры x86 затем интегрировали эту функциональность x87 в чип, что сделало инструкции x87 де-факто неотъемлемой частью набора инструкций x86. Каждый регистр x87, известный как от ST(0) до ST(7), имеет ширину 80 бит и хранит числа в стандартном формате IEEE с плавающей запятой с двойной расширенной точностью.

Также связан этот другой вопрос SO: Некоторая точность с плавающей запятой и вопрос числовых ограничений

Это могло бы объяснить, почему, хотя двойные числа являются 64-битными, они обрабатываются атомарно.

Для чего стоит эта тема и пример кода можно найти здесь.

http://msdn.microsoft.com/en-us/magazine/cc817398.aspx