Safe to use stdatomic.h?

Safe to use stdatomic.h?

[Ben Peart]

My college Jeff is working on a patch series to further parallelize the
loading of the index.  As part of that patch, it would be nice to use the
atomic_fetch_add function as that would be more efficient than creating a
mutex simply to protect a variable so that it can be incremented.  I haven't
seen any use of atomics yet in Git, nor anything that includes
<stdatomic.h>.

GCC has supported them since 4.9 and Clang has supported them by default
since 3.3.  Are there any compilers currently in use by Git that don't
support these C11 functions?

Thanks,

Ben

Re: Safe to use stdatomic.h?

[Jeff King]

On Mon, Mar 20, 2017 at 04:18:20PM -0400, Ben Peart wrote:

> My college Jeff is working on a patch series to further parallelize the
> loading of the index.  As part of that patch, it would be nice to use the
> atomic_fetch_add function as that would be more efficient than creating a
> mutex simply to protect a variable so that it can be incremented.  I haven't
> seen any use of atomics yet in Git, nor anything that includes
> <stdatomic.h>.
> 
> GCC has supported them since 4.9 and Clang has supported them by default
> since 3.3.  Are there any compilers currently in use by Git that don't
> support these C11 functions?

Yes, there definitely are older compilers in use. However, if you can
abstract the operation you want to perform into its own function, it's
perfectly fine to #ifdef it to use the atomics when available and fall
back to a mutex otherwise.

-Peff

Re: Safe to use stdatomic.h?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

On Mon, Mar 20, 2017 at 04:18:20PM -0400, Ben Peart wrote:
> My college Jeff is working on a patch series to further parallelize the
> loading of the index.  As part of that patch, it would be nice to use the
> atomic_fetch_add function as that would be more efficient than creating a
> mutex simply to protect a variable so that it can be incremented.  I haven't
> seen any use of atomics yet in Git, nor anything that includes
> <stdatomic.h>.
> 
> GCC has supported them since 4.9 and Clang has supported them by default
> since 3.3.  Are there any compilers currently in use by Git that don't
> support these C11 functions?

At work, we're compiling for CentOS 6 and 7.  CentOS 7 only has GCC 4.8,
and CentOS 6 has something much older.  This is code we ship to
customers, so we can't rely on them having devtoolset installed for
newer GCC.

I could support the argument for ditching RHEL/CentOS 5 support, but I
expect other people might disagree.  After all, we're still targeting
C89.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

Re: Safe to use stdatomic.h?

[Eric Wong]

"brian m. carlson" <sandals@crustytoothpaste.net> wrote:
> I could support the argument for ditching RHEL/CentOS 5 support, but I
> expect other people might disagree.  After all, we're still targeting
> C89.

Yeah, I still use and support CentOS 5 in some places (but maybe
not git, still using ancient versions there, too).

Anyways, I'm still relying on the traditional __sync_* builtins
from in earlier gcc 4.x releases in some code GPL-3.0 code I
maintain for older systems:

	https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html

Since git is GPL-2.0, it is license-compatible with all the
atomic macros in the Linux kernel, as well as the kernel-derived
userspace atomics (uatomic) found in liburcu <http://liburcu.org/>