Kernelspace C11 atomics for MIPS

Konstantin Belousov kostikbel at gmail.com
Tue Jun 4 16:56:59 UTC 2013


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.
> > 
> > I'm a bit wary of *kernel* developers using C11-native atomics as opposed
> > to our own atomic API.  This could lead to a proliferation of home-grown,
> > more or less correctly working, locks and variants thereof (mostly less
> > correct).
> 
> I think this is not a big deal to worry about as developers have already been 
> free to do this via <machine/atomic.h> and haven't gone super crazy.  
> Replacing <machine/atomic.h> with <sys/stdatomic.h> is probably fine and 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130604/e09539a3/attachment.sig>


More information about the freebsd-arch mailing list