# Safe to use stdatomic.h? 4 messages from 2017-03-20 to 2017-03-21. Participants: Ben Peart, Jeff King, brian m. carlson, Eric Wong. Thread: https://gitlist.dev/t/45444 ## Ben Peart, 2017-03-20 20:18 Subject: Safe to use stdatomic.h? Message-ID: <000801d2a1b7$1ec41620$5c4c4260$@gmail.com> URL: https://gitlist.dev/e/000801d2a1b7%241ec41620%245c4c4260%24%40gmail.com ``` 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 . 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 ``` ## Jeff King, 2017-03-20 20:27 Subject: Re: Safe to use stdatomic.h? Message-ID: <20170320202755.ospj7o6dfczti6wp@sigill.intra.peff.net> URL: https://gitlist.dev/e/20170320202755.ospj7o6dfczti6wp%40sigill.intra.peff.net In-Reply-To: <000801d2a1b7$1ec41620$5c4c4260$@gmail.com> ``` 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 > . > > 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 ``` ## brian m. carlson, 2017-03-20 23:22 Subject: Re: Safe to use stdatomic.h? Message-ID: <20170320232240.k3egololfj7wt5cf@genre.crustytoothpaste.net> URL: https://gitlist.dev/e/20170320232240.k3egololfj7wt5cf%40genre.crustytoothpaste.net In-Reply-To: <000801d2a1b7$1ec41620$5c4c4260$@gmail.com> ``` 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 > . > > 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 ``` ## Eric Wong, 2017-03-21 01:59 Subject: Re: Safe to use stdatomic.h? Message-ID: <20170321015948.GC6536@starla> URL: https://gitlist.dev/e/20170321015948.GC6536%40starla In-Reply-To: <20170320232240.k3egololfj7wt5cf@genre.crustytoothpaste.net> ``` "brian m. carlson" 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 ```