From: Nick Piggin <nickpiggin@yahoo.com.au>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@osdl.org, keyrings@linux-nfs.org,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] Keys: Improve usage of memory barriers and remove IRQ disablement
Date: Wed, 05 Apr 2006 19:23:58 +1000 [thread overview]
Message-ID: <44338CAE.6060206@yahoo.com.au> (raw)
In-Reply-To: <29064.1144226770@warthog.cambridge.redhat.com>
David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> | int atomic_inc_and_test(atomic_t *v);
> | int atomic_dec_and_test(atomic_t *v);
> |
> | These two routines increment and decrement by 1, respectively, the
> | given atomic counter. They return a boolean indicating whether the
> | resulting counter value was zero or not.
> |
> | It requires explicit memory barrier semantics around the operation as
> | above.
>
> Note the last paragraph. "It requires" should be "They require", but the
> sense would seem to be obvious. However, it's not clear on a second reading
> as to whether this is an instruction to the _caller_ or an instruction to the
> arch _implementer_.
>
Yes, I remember Dave M clarified this sometime ago (on lkml I guess). It
is a little confusing, but I think the wording is for the implementer's
point of view. Dave will pull me up if I'm wrong...
> I suppose from reading the abstract at the top:
>
> | This document is intended to serve as a guide to Linux port maintainers on
> | how to implement atomic counter, bitops, and spinlock interfaces properly.
>
> that it is meant to be read by the implementor and not the user/caller, in which
> case, Nick is correct.
>
> It seems I need to adjust my memory barrier doc, and perhaps I should adjust
> atomic_ops.txt too to make it clearer.
>
I think that would be good. atomic_ops.txt is very useful for API users
as well, so if it can be made more general without becoming ambiguous,
I'm sure that would be appreciated.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-04-05 21:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-04 9:55 [PATCH] Keys: Improve usage of memory barriers and remove IRQ disablement David Howells
2006-04-04 10:23 ` [Keyrings] " David Howells
2006-04-04 10:58 ` Nick Piggin
2006-04-05 8:46 ` David Howells
2006-04-05 9:23 ` Nick Piggin [this message]
2006-04-05 22:51 ` David S. Miller
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=44338CAE.6060206@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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.