From: Arnd Bergmann <arnd@arndb.de>
To: Paul Mackerras <paulus@samba.org>
Cc: benh@kernel.crashing.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
Date: Sat, 13 Jun 2009 23:53:38 +0200 [thread overview]
Message-ID: <200906132353.39269.arnd@arndb.de> (raw)
In-Reply-To: <18995.20685.227683.561827@cargo.ozlabs.ibm.com>
On Saturday 13 June 2009, Paul Mackerras wrote:
> +extern long long atomic64_read(const atomic64_t *v);
> +extern void atomic64_set(atomic64_t *v, long long i);
> +extern void atomic64_add(long long a, atomic64_t *v);
> +extern long long atomic64_add_return(long long a, atomic64_t *v);
> +extern void atomic64_sub(long long a, atomic64_t *v);
> +extern long long atomic64_sub_return(long long a, atomic64_t *v);
> +extern long long atomic64_dec_if_positive(atomic64_t *v);
> +extern long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n);
> +extern long long atomic64_xchg(atomic64_t *v, long long new);
> +extern int atomic64_add_unless(atomic64_t *v, long long a, long long u);
> +
> +#define atomic64_add_negative(a, v) (atomic64_add_return((a), (v)) < 0)
> +#define atomic64_inc(v) atomic64_add(1LL, (v))
> +#define atomic64_inc_return(v) atomic64_add_return(1LL, (v))
> +#define atomic64_inc_and_test(v) (atomic64_inc_return(v) == 0)
> +#define atomic64_sub_and_test(a, v) (atomic64_sub_return((a), (v)) == 0)
> +#define atomic64_dec(v) atomic64_sub(1LL, (v))
> +#define atomic64_dec_return(v) atomic64_sub_return(1LL, (v))
> +#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
> +#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
> +
How about also doing these:?
#define atomic64_sub(a, v) atomic64_add(-a, v)
#define atomic64_sub_return(a, v) atomic64_add_return(-a, v)
#define atomic64_add(a, v) (void)atomic64_add_return(a, v)
The cost to the caller (one or two instruction per call site)
seems to be about the same as for the other wrapper macros.
Arnd <><
next prev parent reply other threads:[~2009-06-13 21:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 7:10 [PATCH 1/2] lib: Provide generic atomic64_t implementation Paul Mackerras
2009-06-13 20:13 ` Linus Torvalds
2009-06-13 20:25 ` Linus Torvalds
2009-06-13 20:56 ` Ingo Molnar
2009-06-14 11:53 ` Avi Kivity
2009-06-14 12:21 ` Paul Mackerras
2009-06-14 13:04 ` Avi Kivity
2009-06-15 2:44 ` Roland Dreier
2009-06-15 4:30 ` Paul Mackerras
2009-06-16 22:27 ` Gabriel Paubert
2009-06-13 21:53 ` Arnd Bergmann [this message]
2009-06-18 23:55 ` Mike Frysinger
2009-06-19 0:46 ` Benjamin Herrenschmidt
2009-06-19 0:47 ` Paul Mackerras
2009-06-19 0:49 ` Mike Frysinger
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=200906132353.39269.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox