On 07/15/2012 11:49 PM, Hans-Peter Nilsson wrote:
Well, give up by default that is, and fix it up in a helper function in glibc to hold a global byte-sized atomic lock for the duration. (Sorry!) Yes, this means that fold_builtin_atomic_always_lock_free is wrong. It knows about alignment in general but doesn't handle the case where the default alignment of the underlying type is too small for atomic accesses, and should probably be augmented by a target hook, alternatively, change the allow_libcall argument in the call to can_compare_and_swap_p to false. I guess I should open a PR for this and add a test-case. Later.
I set it up to eventually handle alignment issues, but didn't really know any details of what to do when, or how. Input was rather lacking at the time and there was a time crunch, so I just punted on it in 4.7 at the tree level and targets did their own thing. The library idea was new enough that the standards guys couldnt/wouldn't give me a straight answer since it hadn't really been thought through I don't think. My apologies if I misrepresent anyone there :-)
The basic problem you are dealing with is a 4 byte object that is not aligned properly, so the lock-free instructions don't work on it., but 'always_lock_free' says "yes, that type is lock free". Then in the library, its implemented via a lock? Is that approximately it? or is there an additional issue?
The original intention was that __atomic{is,always}_lock_free takes the size and a pointer to the object, and the alignment of the pointer object would be checked at compile time to see if it is always compatible with size. (so a char pointer to a 4 byte object would fail that test). which would means 'always_lock_free' should return false, and in turn a call to 'is_lock_free' would generate a library call and check the alignment at runtime of the object to determine what to do. The library implementation of all the other __atomic operations would check 'is_lock_free' to see whether they need to use a lock, or whether they can use available lock-free sequences/syscalls.
Some confusion around the standard surfaced and the intention from the standard point of view appeared to be that 'is_lock_free' should be true or false ALL the time for a given type. This possibly is related to the separation of gcc's built-ins from the implementation details of the standard (ie the standard uses the built-ins but only with aligned objects, but those built-ins can also still be used outside the standard in more chaotic ways)
So in the end, i wasn't sure what to do and ran out of time. Making it better for 4.8 would be goodness. Is there a fatal flaw in the original (unimplemented) intention? if so, can it be fixed without changing the API?
Any PR's you open related this this, copy me on them and I'll try to get them addressed.
Andrew
