All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH,RESEND] documentation: atomic_add_unless() doesn't imply mb() on failure
Date: Thu, 23 Aug 2007 16:49:53 +1000	[thread overview]
Message-ID: <46CD2E11.6080301@yahoo.com.au> (raw)
In-Reply-To: <20070817193453.GA198@tv-sign.ru>

Oleg Nesterov wrote:
> (the explicit ack/nack from maintainers is wanted).
> 
> A "typical" implementation of atomic_add_unless() can return 0 immediately
> after the first atomic_read() (before doing cmpxchg). In that case it doesn't
> provide any barrier semantics. See include/asm-ia64/atomic.h as an example.
> 
> We should either change the implementation, or fix the docs.

Did this end up getting merged? If not, it should, thanks.

Acked-by: Nick Piggin <npiggin@suse.de>

> 
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
> 
>  Documentation/atomic_ops.txt      |    3 ++-
>  Documentation/memory-barriers.txt |    2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff -puN Documentation/atomic_ops.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure Documentation/atomic_ops.txt
> --- a/Documentation/atomic_ops.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure
> +++ a/Documentation/atomic_ops.txt
> @@ -137,7 +137,8 @@ If the atomic value v is not equal to u,
>  returns non zero. If v is equal to u then it returns zero. This is done as
>  an atomic operation.
>  
> -atomic_add_unless requires explicit memory barriers around the operation.
> +atomic_add_unless requires explicit memory barriers around the operation
> +unless it fails (returns 0).
>  
>  atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
>  
> diff -puN Documentation/memory-barriers.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure Documentation/memory-barriers.txt
> --- a/Documentation/memory-barriers.txt~doc-atomic_add_unless-doesnt-imply-mb-on-failure
> +++ a/Documentation/memory-barriers.txt
> @@ -1492,7 +1492,7 @@ about the state (old or new) implies an 
>  	atomic_dec_and_test();
>  	atomic_sub_and_test();
>  	atomic_add_negative();
> -	atomic_add_unless();
> +	atomic_add_unless();	/* when succeeds (returns 1) */
>  	test_and_set_bit();
>  	test_and_clear_bit();
>  	test_and_change_bit();
> _
> 
> 


-- 
SUSE Labs, Novell Inc.

      reply	other threads:[~2007-08-23  6:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-17 19:34 [PATCH,RESEND] documentation: atomic_add_unless() doesn't imply mb() on failure Oleg Nesterov
2007-08-23  6:49 ` Nick Piggin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46CD2E11.6080301@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@tv-sign.ru \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.