On Tue, 2018-02-27 at 19:32 +0000, Ruslan Nikolaev wrote: > > > 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).
The types that are machine-word-sized and less determine what the default is. The 128b types are the outlier, and they should conform to what we want for all other types. The context of my statement was which the producer-consumer example I brought up. > > 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. You brought up the 128b case, and claimed that there was no proper solution for it. Now you are saying it's an invalid example. If it is, then I don't see what you are trying to argue for. > 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"). You wanted to have something that's portable, and focused on the C standard. Now you are saying this doesn't matter anymore. This seems inconsistent. My statement was in the context of portable C/C++ programs. > Given that it is not a very common use case, does not seem to need to have > special C standard for this. Did you mean to say that the fact that there's no support in ISO C for it means that it's not a use case it matters? If so, that's not the case. The standards simply don't support all use cases that have relevance to their users. > 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. We discussed this topic already. I'm not going to repeat myself. > 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. I don't have any opinion on what you personally use or don't use. I care about GCC users as a whole, of course. But it seems to me we discussed all aspects of this, so I'd prefer this discussion to eventually conclude.
