{"thread":{"id":"45444","subject":"Safe to use stdatomic.h?","startedAt":"2017-03-20T20:19:49Z","lastAt":"2017-03-21T01:59:53Z","messageCount":4,"participants":["Ben Peart","Jeff King","brian m. carlson","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"314724","messageId":"000801d2a1b7$1ec41620$5c4c4260$@gmail.com","threadId":"45444","inReplyTo":null,"subject":"Safe to use stdatomic.h?","fromName":"Ben Peart","fromEmail":"peartben@gmail.com","sentAt":"2017-03-20T20:18:20Z","receivedAt":"2017-03-20T20:19:49Z","isPatch":false,"sender":{"key":"benpeart@microsoft.com","avatar":"https://avatars.githubusercontent.com/u/15252029?v=4"},"body":"My college Jeff is working on a patch series to further parallelize the\nloading of the index. As part of that patch, it would be nice to use the\natomic_fetch_add function as that would be more efficient than creating a\nmutex simply to protect a variable so that it can be incremented. I haven't\nseen any use of atomics yet in Git, nor anything that includes\n.\n\nGCC has supported them since 4.9 and Clang has supported them by default\nsince 3.3. Are there any compilers currently in use by Git that don't\nsupport these C11 functions?\n\nThanks,\n\nBen\n\n\n"},{"id":"314725","messageId":"20170320202755.ospj7o6dfczti6wp@sigill.intra.peff.net","threadId":"45444","inReplyTo":"000801d2a1b7$1ec41620$5c4c4260$@gmail.com","subject":"Re: Safe to use stdatomic.h?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-20T20:27:55Z","receivedAt":"2017-03-20T20:29:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 20, 2017 at 04:18:20PM -0400, Ben Peart wrote:\n\n> My college Jeff is working on a patch series to further parallelize the\n> loading of the index. As part of that patch, it would be nice to use the\n> atomic_fetch_add function as that would be more efficient than creating a\n> mutex simply to protect a variable so that it can be incremented. I haven't\n> seen any use of atomics yet in Git, nor anything that includes\n> .\n> \n> GCC has supported them since 4.9 and Clang has supported them by default\n> since 3.3. Are there any compilers currently in use by Git that don't\n> support these C11 functions?\n\nYes, there definitely are older compilers in use. However, if you can\nabstract the operation you want to perform into its own function, it's\nperfectly fine to #ifdef it to use the atomics when available and fall\nback to a mutex otherwise.\n\n-Peff\n"},{"id":"314746","messageId":"20170320232240.k3egololfj7wt5cf@genre.crustytoothpaste.net","threadId":"45444","inReplyTo":"000801d2a1b7$1ec41620$5c4c4260$@gmail.com","subject":"Re: Safe to use stdatomic.h?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2017-03-20T23:22:40Z","receivedAt":"2017-03-20T23:30:20Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Mar 20, 2017 at 04:18:20PM -0400, Ben Peart wrote:\n> My college Jeff is working on a patch series to further parallelize the\n> loading of the index. As part of that patch, it would be nice to use the\n> atomic_fetch_add function as that would be more efficient than creating a\n> mutex simply to protect a variable so that it can be incremented. I haven't\n> seen any use of atomics yet in Git, nor anything that includes\n> .\n> \n> GCC has supported them since 4.9 and Clang has supported them by default\n> since 3.3. Are there any compilers currently in use by Git that don't\n> support these C11 functions?\n\nAt work, we're compiling for CentOS 6 and 7. CentOS 7 only has GCC 4.8,\nand CentOS 6 has something much older. This is code we ship to\ncustomers, so we can't rely on them having devtoolset installed for\nnewer GCC.\n\nI could support the argument for ditching RHEL/CentOS 5 support, but I\nexpect other people might disagree. After all, we're still targeting\nC89.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"314771","messageId":"20170321015948.GC6536@starla","threadId":"45444","inReplyTo":"20170320232240.k3egololfj7wt5cf@genre.crustytoothpaste.net","subject":"Re: Safe to use stdatomic.h?","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2017-03-21T01:59:48Z","receivedAt":"2017-03-21T01:59:53Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"\"brian m. carlson\" wrote:\n> I could support the argument for ditching RHEL/CentOS 5 support, but I\n> expect other people might disagree. After all, we're still targeting\n> C89.\n\nYeah, I still use and support CentOS 5 in some places (but maybe\nnot git, still using ancient versions there, too).\n\nAnyways, I'm still relying on the traditional __sync_* builtins\nfrom in earlier gcc 4.x releases in some code GPL-3.0 code I\nmaintain for older systems:\n\n\thttps://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html\n\nSince git is GPL-2.0, it is license-compatible with all the\natomic macros in the Linux kernel, as well as the kernel-derived\nuserspace atomics (uatomic) found in liburcu \n"}]}