On 10/26/2011 08:29 AM, Michael Matz wrote:
Hi,
On Tue, 25 Oct 2011, Andrew MacLeod wrote:
and new generic routines are provided as follows:
void __atomic_load (T* object, T* return_value, memory_order m)
void __atomic_store (T* object, T* new_value, memory_order m)
void __atomic_exchange (T* object, T* new_value, T* return_value, memory_order
m)
void __atomic_compare_exchange (T* object, T* expected_value, T* new_value,
bool weak, memory_order success, memory_order fail)
When a generic routine is called with an object whose size maps to one
of the type specific built-ins, (ie sizeof (T) == 1,2,4,8 or 16) the
generic call is translated into the appropriate direct call.
Are the generic routines really generic? In particular do they accept
objects that aren't naturally aligned and are supposed to still work? In
that case you can't rewrite them into the type specific builtins after
only checking the size, you also need to check alignment.
yes, ive been considering that. At the moment, the claim is it is well
defined for properly aligned objects, undefined otherwise.
I've been considering what would be involved in defining it. And I not
sure if that should wait until the next release, or whether we should
try now.
- The 5 size specific routines *must* be properly aligned. (ie, and N
byte object must have the same alignment as the N byte integral)
for the generic routines:
- if it can be determined at compile time that the object being
pointed to is properly aligned, then it can be mapped into one of the 5
size specific routines. Otherwise it must remain a call into the
runtime library.
- The runtime library can look at the pointer value and determine if
things are properly aligned based on the pointer value. If properly
aligned, then it could invoke one of the runtime lock-free routines.
- If an improperly aligned pointer is passed in, the fall back would
be to resort to what will probably be a locked implementation for the
object.
- the __atomic_is_lock_free(size) routine will have to have an
additional object pointer parameter. If its NULL, it will return a value
based on properly aligned objects of SIZE. Otherwise, it will also
check the value of the pointer to see if it is properly aligned and then
return true or false based on whether one of the lock-free routines will
be invoked.
So it would mean that an 8 byte object which is properly aligned could
be lock free, while and unaligned 8 byte object would likely have a
locked implementation. They would all work though, just requiring the
library.
Thats my thoughts... I'm tempted to implement the alignment
checking... It seems more complete, but it is more complex. so I waffle :-)
any other opinions?