[cpp-threads] A question about N2153

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Jan 17 19:20:30 GMT 2007


On Wed, Jan 17, 2007 at 08:44:00PM +0200, Peter Dimov wrote:
> What is the reference implementation of acquire_fence for x86, SPARC RMO,
> PowerPC, IA-64? I'm guessing (no op), #LoadLoad | #LoadStore, lwsync, mf.

Stupid side question...  Why acquire_fence and release_fence?  This is
the only group I have come across that uses these.  Where I come from,
we use the following types:

1.	smp_mb/mb: LoadLoad|LoadStore|StoreLoad|StoreStore (1238)
2.	smp_rmb/rmb: LoadLoad (234)
3.	smp_wmb/wmb: StoreStore (716)
4.	rcu_dereference/smp_read_barrier_depends/read_barrier_depends: (225)

#4 forces the CPU to respect ordering for data dependencies.  The number
in parentheses is the number of times that the category appears in
the 2.6.19 Linux kernel, and is slightly inaccurate since it includes
definitions on >20 CPU families but excludes indirect uses via wrapper
functions and macros.

Enlightenment?

						Thanx, Paul

> If we take the example:
> 
> if( fetchadd_release( &ref_count, -1 ) == 1 ) // old value
> {
>    acquire_fence();
>    destroy_object();
> }
> 
> this is fine on x86/SPARC. On PowerPC, however, the most efficient
> implementation has an isync instead of lwsync, right? On IA-64 an ld.acq
> from ref_count may also be more efficient than a mf.
> 
> Since a load_acquire( location ) on PowerPC is (pseudocode):
> 
> mov r1, location
> cmp r1, r1
> bne- $
> isync
> 
> (correct? :-) ) it seems to me that a more efficient formulation of the
> example would be:
> 
> if( fetchadd_release( &ref_count, -1 ) == 1 ) // old value
> {
>    load_acquire( &ref_count );
>    destroy_object();
> }
> 
> This is not guaranteed to work in theory, but I think that it will work in
> practice on all implementations (and the extra load can be optimized out on
> non-IA-64). If I'm right, this might pose a problem. It's not good if
> something not backed by the official specification works better in practice.
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads



More information about the cpp-threads mailing list