On 10/12/2011 09:40 PM, John McCall wrote: > On Oct 12, 2011, at 6:27 PM, Eli Friedman wrote: >> On Wed, Oct 12, 2011 at 6:06 PM, John McCall<[email protected]> wrote: >>> On Oct 12, 2011, at 2:54 PM, Andrew MacLeod wrote: >>>> I'm still not sure I see how it matters. Nothing should ever access or >>>> change that padding field in an unfriendly way since it is always part of >>>> the atomic word that is load/stored, exchanged or compare_exchanged. Those >>>> are the only 4 ways to access the memory. All the fetch_op's only operate >>>> on full integral values, so thats not a concern. Compare_exchange is the >>>> only one which it could be affected, and it requires that the 'expected' >>>> value be from an atomic load or exchange… >>> I wasn't aware of that. That's really a very strange constraint — why is >>> it illegal to independently assemble a value that I expect might be in an >>> atomic variable? >> The standard doesn't make any guarantees about the layout of >> std::atomic<T>; how exactly could you manipulate the bits of an >> std::atomic<T> in a cross-platform manner? > You couldn't, but that's not what I said. I'm saying that it's strange > that the expected value of a compare& exchange is apparently > not permitted to be a T that I've constructed in an arbitrary way; > it has to be a T that I've read with an atomic load or exchange.
1) Actually, the generic interface breaks if the atomic type is not the same size as the base type. void __atomic_exchange (size_t size, void *ptr, void *expected, void *desired,...); in reality, from GCC's point of view, it currently doesn't distinguish an atomic type from the base type, it just sees: void __atomic_exchange(T *ptr, T *expected, T *desired, ...) if 'expected' and 'desired' were different sizes than 'ptr', we'd need another size parameter and have to deal with padding code, and I'm not prepared to go down that road just yet. So my current GCC plan for this release is to always keep stuff the same size... if its a 3 byte object, its 3 bytes and will call the generic routine. I think arbitrary size support is something that will always be needed. It might be worth considering a helpful warning flag that would indicate in this case that "4 byte objects are lock free on this target, increase the size of your object if you would like to take advantage of it." We can add additional interface(s) in the next release to satisfy whatever long term goals are decided upon before then, something like void __atomic_exchange(size_t atomic_size, size_t size, void * atomic_ptr, void * expected, void *desired,...) which can included padded atomics or whatever else we arrive at. There clearly hasn't been enough thought put into the long term design of this to commit to anything yet. And with C not properly defined yet, I doubt anyone is locking their system future into this release. 2) If the language allows an arbitrary class to be atomic, its not fair to issue an error if its not lock free. There is nothing that says an atomic class has to be lock free, and it even provides a method to ask if its lock free.. I think there is a large class of consumers of the language that are going to think its pretty useless if I cant just say 'class employee' is atomic and have it work. Lawrence had to convince me that a locked implementation should reside in an external library rather than be provided by the language. I do intend to provide a simple buildable library from the old libstdc++ locked implementation so that joe blow user (or myself) can resolve his external routines if need be. Are there any issues with those 2 points? Andrew _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
