On 10/01/2011 02:55 AM, Marc Glisse wrote:
"The compiler must ensure that for any given object, it either ALWAYS
inlines lock free routines, OR calls the external routines. For any
given object, these cannot be intermixed."
Why? You give an example explaining why it is fine to link 386 and 486
objects, and I cant see the difference. Not that I'm advocating mixing
them, just wondering whether it really matters if it happens (by
accident).
If we have an architecture which we cannot generate one of the functions
for, say __atomic_load_16, then it will have to use whatever the library
supplies. If you continues to generate all the rest of the __atomic
builtins for 16 bytes using lock free instructions, and the call to the
library turns out to be a locked implementation at runtime, then atomic
support for 16 byte objects is broken. The load thinks its getting a
lock, but none of the other routines pay any attention to locks. So if
one atomic operations requires then library, they all do in order to get
consistent behaviour.
I assume that locks are supposed to be implemented in terms of those
functions too (it sounds like lock uses atomic which uses lock ;-)
For the atomic version of a user-defined "small" POD type, do you
intend to query the compiler about the presence of a volatile member
to dispatch to the right function?
if it is sorted out that volatile does require something different, then
we'd need to dispatch differently for volatile. At the moment Im not
doing anything different for them, just asking "the experts" if we need
to :-) I suspect we might need to, but Its easier to add something
later than to remove something thats already in a compiler.
The design looks a lot like:
http://libcxx.llvm.org/atomic_design_a.html
which is good since the main point seems to be to share it between
implementations. Are there others on board?
Im not aware that anyone has done anything with an external library
yet. Hopefully this will make us all aware of each other and get
consistent :-). I hadn's seen that link, I guess the name is a good
choice :-)
Andrew
