> But we're not talking about that special case of 128b types here. The > majority of synchronization doesn't need more than machine word size. Then why do you worry about read-only access for 128b types? (it is a special case anyway).
> No, such a program would have a bug anyway. It wouldn't even > synchronize properly. Therefore, it was not a valid example / use case (for 128-bit) in the first place. It was a *valid* example for smaller atomics, though. But that is exactly my point -- your current solution for 128 bit does not add any practical value except when you want to use lock-based solution (but see my explanation below). > The lock would need to be shared between processes in the example I > gave. You have to build your own lock for that currently, because C/C++ > don't give you any process-shared locks. At least in Linux, you can simply use eventfd(2) to reliably do it (without relying on "array of locks"). Given that it is not a very common use case, does not seem to need to have special C standard for this. And whatever C11 provides can not be relied upon anyway since you do not have strict guarantees that read-only memory is supported for larger types. For example, clang (and possibly other compilers) will break this assumption. At least, I would prefer to use eventfd in my application (if ever needed at all) since it has reliable and well-defined behavior in Linux.
