lkml.org 
[lkml]   [2006]   [Apr]   [6]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 05 Apr 2006 19:32:25 +1000
FromNick Piggin <>
SubjectRe: [PATCH] Fix memory barrier docs wrt atomic ops
David Howells wrote:

>  ATOMIC OPERATIONS
>  -----------------
> 
> -Though they are technically interprocessor interaction considerations, atomic
> -operations are noted specially as they do _not_ generally imply memory
> -barriers.  The possible offenders include:
> +Whilst they are technically interprocessor interaction considerations, atomic
> +operations are noted specially as some of them imply full memory barriers and
> +some don't, but they're very heavily relied on as a group throughout the
> +kernel.
> +
> +Any atomic_t operation, for instance, that returns a value implies an
> +SMP-conditional general memory barrier (smp_mb()) on each side of the actual
> +operation.  These include:

Actually: this only applies to operations which _both_ modify their atomic_t
operand and return a value. Eg. atomic_read() does not have barrier semantics.

> 
> -	xchg();
> -	cmpxchg();
> -	test_and_set_bit();
> -	test_and_clear_bit();
> -	test_and_change_bit();
>  	atomic_cmpxchg();
>  	atomic_inc_return();
>  	atomic_dec_return();
> @@ -1283,20 +1283,30 @@ barriers.  The possible offenders includ
>  	atomic_add_negative();
>  	atomic_add_unless();
> 
> -These may be used for such things as implementing LOCK operations or controlling
> -the lifetime of objects by decreasing their reference counts.  In such cases
> -they need preceding memory barriers.
> 
> -The following may also be possible offenders as they may be used as UNLOCK
> -operations.
> +The following, however, do _not_ imply memory barrier effects:
> +
> +	xchg();
> +	cmpxchg();
> +	test_and_set_bit();
> +	test_and_clear_bit();
> +	test_and_change_bit();
> +
> +These may be used for such things as implementing LOCK-class operations.  In
> +such cases they need explicit memory barriers.
> +

I believe all the bitops are essentially the same as the atomic semantics.
That is, if they change their operand and return something, they are full
barriers both ways.

atomic_ops.txt says of them:
   "These routines, like the atomic_t counter operations returning values,
    require explicit memory barrier semantics around their execution."

I think we'd have problems at least with TestSetPageLocked if this were
not the case.

I'm not sure if I like the words imply, explicit, implicit, etc. They're
a bit confusing. provide, semantics may be better?

> +The following are also potential offenders as they may be used as UNLOCK-class
> +operations, amongst other things, but do _not_ imply memory barriers either:
> 
>  	set_bit();
>  	clear_bit();
>  	change_bit();
>  	atomic_set();
> 
> +With these the appropriate explicit memory barrier should be used if necessary.
> +
> 

In particular, when clearing a bit to signal the end of a critical section,
clear_bit must be preceeded by smp_mb__before_clear_bit();

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-06 06:33    [from the cache]
©2003-2008