> Есть какое-то число, которое надо сдвинуть на 63 и на 64. Это граничные значения. Как известно, именно граничные значения приносят больше всего неприятностей. Что же будет в res63 и res64? По идее должны быть нули.
Undefined behavior от вычисления res64 будет. Не делайте так.
> выключает прерывания, соответственно, поток в этот период монопольно владеет процессором
Наверное, только одним ядром? Или тут нет SMP?
Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?
Это ядерный мютекс или юзерспейсный? Если юзерспейсный: что если поток завершат принудительно извне в release_mutex() после захвата mutex->ilock? Я как программист ожидаю что все операции над мютексами атомарны.
Ага, конечно. Уважаемый cheremin, прочитайте, хотя бы основные статьи у Hans Boehm по данной теме и выясните, какие проблемы решает C++11 MM. И будет ли работать pthread если C++ MM поломана, и хотя бы Threads Cannot be Implemented as a Library. Во всех реализациях C++ уже была рабочая модель памяти, достаточная для pthread. Да, были разрешены некоторые оптимизации, которые корректны в однопоточных программах, но создают data race на пустом месте в многопоточных. Но почти все эти баги закрыты до формализации модели памяти, потому что иначе даже «элементарщина», как вы выразились, не работала бы.
> Но давайте прикинем — каков объем кода, созданного с с использованием утвержденной С11 модели памяти, и который работает в высоконагруженном продакшене?
Весь многопоточный C++, даже не использующий C++11 threads, даже написанный до формализации этой модели памяти. Основной принцип модели памяти, SC-DRF, был всем очевиден давно, и именно на него ориентировались, просто в C++11 он формализован для этого языка.
> гораздо более сложной модели памяти
Вы разбираетесь в обоих моделях памяти настолько, что можете легко сравнить их сложность для реализации?
Кроме того, при разработке этой модели учтены все грабли, по которой прошлась Java. Кроме того, когда разрабатывалась первая JMM Intel ещё не выпустил в паблик информацию о модели памяти x86.
Примеры багов, связанных с неправильной реализацией модели памяти в gcc или clang — в студию.
Начиная с C++11 и C11 есть модель памяти. Она в целом соответствует тому, что большинство компиляторов уже и так реализовывали. Разница в очень небольших деталях, и эти изменения уже внесены в современные версии компиляторов.
Недостаток реализации с наследованием — обратный порядок элементов кортежа в памяти и медленная компиляция (компиляторам сложнее обрабатывать глубокие иерархии наследования, чем широкие).
В C++11 constexpr функции очень ограничены (запрещено использовать много конструкций), а в C++14 (C++1y) большая часть ограничений была снята. В C++1y в constexpr функциях можно использовать if, switch, циклы, изменять переменные (если их lifetime начался во время вычисления константного выражения), и прочее.
Undefined behavior от вычисления res64 будет. Не делайте так.
Наверное, только одним ядром? Или тут нет SMP?
Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?
Посоветую эти две:
www.amazon.com/Engineering-Compiler-Second-Edition-Cooper/dp/012088478X/
www.amazon.com/Advanced-Compiler-Design-Implementation-Muchnick/dp/1558603204/
Ага, конечно. Уважаемый cheremin, прочитайте, хотя бы основные статьи у Hans Boehm по данной теме и выясните, какие проблемы решает C++11 MM. И будет ли работать pthread если C++ MM поломана, и хотя бы Threads Cannot be Implemented as a Library. Во всех реализациях C++ уже была рабочая модель памяти, достаточная для pthread. Да, были разрешены некоторые оптимизации, которые корректны в однопоточных программах, но создают data race на пустом месте в многопоточных. Но почти все эти баги закрыты до формализации модели памяти, потому что иначе даже «элементарщина», как вы выразились, не работала бы.
> Но давайте прикинем — каков объем кода, созданного с с использованием утвержденной С11 модели памяти, и который работает в высоконагруженном продакшене?
Весь многопоточный C++, даже не использующий C++11 threads, даже написанный до формализации этой модели памяти. Основной принцип модели памяти, SC-DRF, был всем очевиден давно, и именно на него ориентировались, просто в C++11 он формализован для этого языка.
> гораздо более сложной модели памяти
Вы разбираетесь в обоих моделях памяти настолько, что можете легко сравнить их сложность для реализации?
Вот, например, документ аж из 2004-го:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1680.pdf
Кроме того, при разработке этой модели учтены все грабли, по которой прошлась Java. Кроме того, когда разрабатывалась первая JMM Intel ещё не выпустил в паблик информацию о модели памяти x86.
Примеры багов, связанных с неправильной реализацией модели памяти в gcc или clang — в студию.
stackoverflow.com/questions/9641699/why-is-it-not-good-to-use-recursive-inheritance-for-stdtuple-implementations
mitchnull.blogspot.com/2012/06/c11-tuple-implementation-details-part-1.html
isocpp.org/files/papers/N3652.html
Можно попробовать в clang -std=c++1y (Clang брать из SVN, реализация ещё не полная).
Так и запишем: Linux Kernel, GCC, Clang, LLVM — не серьёзные проекты.
llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?revision=176593&view=markup
См. struct __long, struct __short и struct __rep с union внутри.