Здравствуйте, netch80, Вы писали:

N>Ещё можно явно барьеры компилятору ставить через atomic_signal_fence().
N>Записал в одно поле union, поставил барьер, прочитал другое поле.
N>Оптимизация чуть пострадает, но для задачи разбора таких структур, кажется, без разницы, затраты на сеть будут больше.
N>Или WRITE_ONCE + READ_ONCE образца Linux (которые внутри превращаются в volatile-доступы).

Мне как-то даже в голову не приходило делать это через volatile (или эквиавалент).

В принципе, правила этой весёлой игры говорят, что если кастировать через (char*), компилятор должен понять намёк и перечитывать поля.

N>Опять же, по сравнению с затратами на диск и сеть это копеечное время.
N>А если где-то реально становится узким местом... таких немного, их можно и специально обработать.

Я как-то разбирался, почему на какой-то армовской (или PPC? уже не помню...) железке с линухом внутри сеть медленно работает. Оказалось, какой-то альтернативно одаренный (1) включил опцию в ядре, которая ловит исключения по невыровненному доступу к 32-битным данным и эмулироет поведение в стиле x86 (2) не учел, что в заголовке ethernet 14 байт, в результате все IP-заголовки были выровнены на 4N + 2 байта.

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