Date: Tue, 4 Jun 2013 19:23:28 +0200 From: Ed Schouten <ed@80386.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Andre Oppermann <andre@freebsd.org>, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <CAJOYFBBiee3wqr52tf9fCdRXDagXa2yDbTO6cDcRU=ZuBU3A8Q@mail.gmail.com> In-Reply-To: <20130604165652.GT3047@kib.kiev.ua> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <51ADA308.6040904@freebsd.org> <201306040952.51513.jhb@freebsd.org> <20130604165652.GT3047@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
2013/6/4 Konstantin Belousov <kostikbel@gmail.com>:
> 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.
Well, yes, no, it's complicated. The fact is, we are still free to
implement <stdatomic.h> without using those compiler's features. For
example, we could have also decided to implement <stdatomic.h> using
only code we provide ourselves, as follows:
static inline int8_t
our_8bit_atomic_store(...)
{
...
}
#define atomic_store(...) _Generic( \
int8_t: our_8bit_atomic_store(....), \
... \
)
Also, it is extremely unlikely that compilers implement handlers for
non-lock-free atomics themselves. Both Clang and GCC 4.7+, for
example, will call into __atomic_*_{1,2,4,8,16,c}() whenever it does
not know built-in CPU instructions to perform the operation. More
details:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
So in my opinion there are tons of ways we can still influence how the
atomic operations are performed. The patch I sent out already
demonstrates this, as we are free to implement the GCC intrinsics the
way we like.
--
Ed Schouten <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBBiee3wqr52tf9fCdRXDagXa2yDbTO6cDcRU=ZuBU3A8Q>