This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC interpretation of C11 atomics (DR 459)
- From: "Ruslan Nikolaev via gcc" <gcc at gcc dot gnu dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Simon Wright <simon at pushface dot org>, Alexander Monakov <amonakov at ispras dot ru>, Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GCC Patches <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Feb 2018 19:32:39 +0000 (UTC)
- Subject: Re: GCC interpretation of C11 atomics (DR 459)
- Authentication-results: sourceware.org; auth=none
- References: <886227277.5611063.1519759959364.ref@mail.yahoo.com>
- Reply-to: Ruslan Nikolaev <nruslan_devel at yahoo dot com>
- Reply-to: Ruslan Nikolaev <nruslan_devel at yahoo dot com>
> 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.