Говоря о модели памяти С++ для concurrency, язык программирования Stroustrup С++, 4-е изд., раздел. 41.2.1, говорит:
... (как и большинство современных аппаратных средств), машина не могла загружать или хранить что-либо меньшее, чем слово.
Однако, мой процессор x86, несколько лет назад, может хранить и хранить объекты, меньшие, чем слово. Например:
#include <iostream>
int main()
{
    char a =  5;
    char b = 25;
    a = b;
    std::cout << int(a) << "\n";
    return 0;
}
Без оптимизации GCC компилирует это как:
        [...]
        movb    $5, -1(%rbp)   # a =  5, one byte
        movb    $25, -2(%rbp)  # b = 25, one byte
        movzbl  -2(%rbp), %eax # load b, one byte, not extending the sign
        movb    %al, -1(%rbp)  # a =  b, one byte
        [...]
Комментарии принадлежат мне, но сборка осуществляется GCC. Конечно, это нормально.
Очевидно, я не понимаю, о чем говорит Страуструп, когда объясняет, что аппаратное обеспечение может загружать и хранить ничего меньше слова. Насколько я могу судить, моя программа ничего не делает, кроме загрузки и хранения объектов, меньших, чем слово.
Тщательная фокусировка С++ на нулевой стоимости, аппаратные абстракции устанавливает С++ отдельно от других языков программирования, которые легче освоить. Поэтому, если Stroustrup имеет интересную ментальную модель сигналов на шине или что-то еще такого рода, то я хотел бы понять модель Страуструпа.
Что говорит Страуструп, пожалуйста?
ДОЛГОЙ ЦИТАТЫ С КОНТЕКСТОМ
Вот цитата Stroustrup в более полном контексте:
Рассмотрим, что может произойти, если компоновщик выделил [переменные типа
charтипа]cиbв одном и том же слове в памяти и (как и большинство современных аппаратных средств), машина не могла загружать или хранить что-либо меньшее, чем слово.... Без четко определенной и разумной модели памяти поток 1 может читать слово, содержащееbиc, изменитьcи записать слово обратно в память. В то же время поток 2 может сделать то же самое сb. Затем, какой бы нити ни удалось прочитать слово первым, и какой бы нить не удавалось записать свой результат обратно в память, последний определял бы результат....
ДОПОЛНИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
Я не верю, что Страуструп говорит о линиях кеша. Даже если бы он был, насколько я знаю, протоколы когерентности кеширования будут прозрачно обрабатывать эту проблему, за исключением, может быть, во время аппаратного ввода-вывода.
Я проверил данные моего процессора. Электрически мой процессор (модем Intel Ivy Bridge), похоже, обращается к памяти DDR3L с помощью своего рода 16-разрядной схемы мультиплексирования, поэтому я не знаю, что это значит. Мне непонятно, что это имеет много общего с точкой Страуструпа.
Страуструп - умный человек и выдающийся ученый, поэтому я не сомневаюсь, что он воспринимает что-то разумное. Я смущен.
См. также этот вопрос. Мой вопрос несколько напоминает связанный вопрос, и ответы на связанный вопрос также полезны здесь. Тем не менее, мой вопрос касается и аппаратной/шинной модели, которая мотивирует С++ таким, каким она есть, и это заставляет Stroustrup писать то, что он пишет. Я не ищу ответа только относительно того, что формально гарантирует стандарт С++, но также хочет понять, почему это гарантировал бы стандарт С++. Какова основная мысль? Это тоже часть моего вопроса.