Date: Tue, 4 Jun 2013 19:56:52 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Ed Schouten <ed@80386.nl>, Andre Oppermann <andre@freebsd.org>, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <20130604165652.GT3047@kib.kiev.ua> In-Reply-To: <201306040952.51513.jhb@freebsd.org> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <51ADA308.6040904@freebsd.org> <201306040952.51513.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--jS6B5y1SGyDdwoJD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2013 at 09:52:51AM -0400, John Baldwin wrote: > On Tuesday, June 04, 2013 4:19:20 am Andre Oppermann wrote: > > On 03.06.2013 16:04, Ed Schouten wrote: > > > Hi, > > > > > > As of r251230, it should be possible to use C11 atomics in > > > kernelspace, by including <sys/stdatomic.h>! Even when not using Clang > > > (but GCC 4.2), it is possible to use quite a large portion of the API. > >=20 > > I'm a bit wary of *kernel* developers using C11-native atomics as oppos= ed > > to our own atomic API. This could lead to a proliferation of home-grow= n, > > more or less correctly working, locks and variants thereof (mostly less > > correct). >=20 > I think this is not a big deal to worry about as developers have already = been=20 > free to do this via <machine/atomic.h> and haven't gone super crazy. =20 > Replacing <machine/atomic.h> with <sys/stdatomic.h> is probably fine and= =20 > should be a simple drop-in replacement for our lock implementations. I do not think so. The compilers are free to use whatever means to implement the stdatomic. In particular, they are allowed to use simple global lock to protect the 'atomic' access, see ATOMIC_type_LOCK_FREE documented macros. IMO using our machine/atomic.h gives us the desirable exact control over the semantic of locks both kernel and usermode C runtime implement. Practically speaking, I think most people there are capable of fixing bugs and extending functionality of machine/atomic.h, but have no desire or time digging into <compiler of the day> to change something. --jS6B5y1SGyDdwoJD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRrhxUAAoJEJDCuSvBvK1BVckP/1ZYaOksy4B8GrcRo2vxCUzp cKoWJJ1hqTmygBMfM0umWi0cyOIQvn15GGzKKwpuNWuUKpZSKGaVDrR9PzPeUwoP N249KNgun+jIEE145WkXaP5DtPg3SEsH1KBWDRjIGHXFDMtBUT6msBf1BToCzKTP 0mMyLA3gG53xuPU6sISQT7pNKEf9WXnua33kEM4j7bdlyKYatvL3EgrbOfS1Gwc6 UDJch3jedXDhPJbD26m5AYQm/oLBEbZfkVgquIa5pDslB4w+7bNK0FimQfd+RrpT BI99dZmhLjS5ra3Udwcn8q+05G02HBfHmNmfmizgVVUwQC/8b64KWmyO6orynE2V QsGsFZWzuE6fxfOkQMFCM0nQQW/jk7zvStEL12wOR/UYIEUdvMHDre02/JOkPNQV qEIupfnyDzjI2cFGVO2ZW/2zbrzaE++bhHhwhq3HDs6s4ZLtZV6joCKYZmDNsfQl vrODQLVpHmiMOJ5BRllk4JXKb3N6pv49HQ0J5oXKjJPDrolAOOrb+FMICEqd0Uuu aTYgaDA0zKbMp4VwBqz4r4QiUC+2tDftW/X+Rs06MWSJIfQF53jyhpyVMO8a2f7t MmhQf2iTMVZzgtEf3+oWNSKrDQkPwcoef09aXmBD5VowFX4MtZa5Dvc5D9OI+r7u e0krjCO8WjPF7INZL43S =BxK5 -----END PGP SIGNATURE----- --jS6B5y1SGyDdwoJD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130604165652.GT3047>