From: liu ping fan <qemulist@gmail.com>
To: Richard Henderson <rth@twiddle.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] atomic: using memory_order_relaxed for refcnt inc/dec ops
Date: Sun, 14 Jul 2013 10:18:31 +0800 [thread overview]
Message-ID: <CAJnKYQmgntydddeNeQS-RmG1-zW1KV4f=uRBJJzjH_LcJC3ZXg@mail.gmail.com> (raw)
In-Reply-To: <51E02DAE.3040204@twiddle.net>
On Sat, Jul 13, 2013 at 12:24 AM, Richard Henderson <rth@twiddle.net> wrote:
> On 07/11/2013 11:32 PM, Liu Ping Fan wrote:
>> Refcnt's atomic inc/dec ops are frequent and its idiom need no seq_cst
>> order. So to get better performance, it worth to adopt _relaxed
>> other than _seq_cst memory model on them.
>
> You'd need to update the documentation then. As it stands, what you've written
> looks like a bug.
>
Ok, will update atomic.txt
>> +#ifndef _GLIBCXX_ATOMIC_BUILTINS
>
> This will never be defined. It's private to the libstdc++ implementation. See
> how we've defined things using __atomic elsewhere in the file, looking at one
> of the __ATOMIC defines.
>
Oh, I misunderstood the description of _GLIBCXX_ATOMIC_BUILTINS. Got
it, thanks.
> And in either case, it's better form to use positive tests than negative ones.
> I.e. #ifdef rather than #ifndef
>
Will fix.
>> #define atomic_fetch_inc(ptr) __sync_fetch_and_add(ptr, 1)
>> #define atomic_fetch_dec(ptr) __sync_fetch_and_add(ptr, -1)
>
> I'd prefer atomic_fetch_inc_relaxed, as that's more self-documenting.
>
But if _relaxed not supported, it will fall back on _seq_cst, then
atomic_fetch_inc_relaxed will be wrong named?
Thanks and regards,
Pingfan
> But I'll re-iterate the necessity of documentation in this area.
>
>
> r~
prev parent reply other threads:[~2013-07-14 2:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 6:32 [Qemu-devel] [PATCH] atomic: using memory_order_relaxed for refcnt inc/dec ops Liu Ping Fan
2013-07-12 16:24 ` Richard Henderson
2013-07-14 2:18 ` liu ping fan [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='CAJnKYQmgntydddeNeQS-RmG1-zW1KV4f=uRBJJzjH_LcJC3ZXg@mail.gmail.com' \
--to=qemulist@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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;
as well as URLs for NNTP newsgroup(s).