[ltt-dev] Userspace RCU library relicensed to LGPLv2.1

[Mathieu Desnoyers]

* Jan Blunck (jblunck at suse.de) wrote:
> On Thu, May 14, Mathieu Desnoyers wrote:
> 
> > If we look at
> > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
> > 
> > The instruction closest to an xchg() instruction (to exchange a pointer
> > in memory) is :
> > 
> > 
> > "type __sync_lock_test_and_set (type *ptr, type value, ...)
> 
> Couldn't you make us of the following?
> 
> type __sync_val_compare_and_swap (type *ptr, type oldval type newval, ...)
> 
>     These builtins perform an atomic compare and swap. That is, if the current
>     value of *ptr is oldval, then write newval into *ptr. 
> 

That would be more expensive. We would need to :

1 - oldval = pointer read (cpu taking the cache line as "shared")
2 - compare and swap newval with *ptr (if *ptr == oldval)
    (cpu taking the cache line as "exclusive")
3 - loop to 2; if it fails, re-using the value returned by compare and
    swap for the next loop

compared to :

oldptr = xchg(&rcu_pointer, newptr);

As you see, using a compare and swap for this is just a waste at many
levels :

- cache line exchanges increase
- code size increase
- code speed decrease

The gcc-friendly solution would be to add a 

type __sync_val_xchg(type *ptr, type value)

primitive to gcc atomic ops.

Mathieu

> At least __sync_lock_test_and_set() and  __sync_lock_release() seem to be only
> usable when implementing spin locks.
> 
> Regards,
> 	Jan
> 
> -- 
> Jan Blunck <jblunck at suse.de>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68