[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1390312776.3008.212.camel@eris.loria.fr>
Date: Tue, 21 Jan 2014 14:59:36 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Discussion of partly-invasive changes needed for x32 port
Am Dienstag, den 21.01.2014, 12:33 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2014-01-21 09:29:01 +0100]:
> > Once you are starting to implement C11 library features, you are going
> > to need more, I think. Implementing C11 atomics without it would be a
> > real challenge.
>
> what is the issue there?
atomic operations are not only defined for the basic types, but any
type may be subject to an _Atomic qualifier or type-specifier.
> i still don't get what the standard mean by "generic function" in the
> c11 atomics specs
I read "generic function" as "function-like type generic macro".
> i thought the compiler will do the hard work (providing __builtin_foo
> for every atomic foo) and libc just macro wraps those
For some basic types, yes, but possibly not for all scalar types
(_Complex double or pointers e.g)
For the aggregate types you'd have to cook up something on the fly
which will usually not be lock-free but use an atomic_flag as a
spinlock.
For a full implementation you will need to distinguish types: a list of
types that have lock free builtins, pointers (most probably map them
to the functions for void*) and other types. Games with sizeof will
usually not suffice for that.
> it is not clear if the atomic functions are reserved for external
> linkage (currently the text seems to require external linkage for them
> but i don't know how could that work)
I think that for all functions mentioned in the standard, this is an
"as-if" rule. The user of these functions should not make any
assumptions how a feature is implemented (external function, builtin,
macro), and in particular any of the standard functions *may* be
implemented as a macro.
> or if you can take the address of them
There I can't imagine how that would work for "type generic functions" :)
> and the standard does not seem to permit the use of atomic functions
> in signal handlers which would be useful
In addition to the functions, for the arithmetic types the usual
operators are defined for all atomic derived types. Compared to the
"generic functions" they have memory_order fixed to
memory_order_seq_cst, IRC.
The standard allows to use all of these operators in signal handlers,
provided that the atomic type is lock-free, for which in turn there
are feature test macros.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
