qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: mttcg@greensocs.com, peter.maydell@linaro.org,
	mark.burton@greensocs.com, a.rigo@virtualopensystems.com,
	qemu-devel@nongnu.org, stefanha@redhat.com,
	fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions
Date: Thu, 4 Feb 2016 13:40:02 +0100	[thread overview]
Message-ID: <56B346A2.6050707@redhat.com> (raw)
In-Reply-To: <87si1ggykz.fsf@linaro.org>



On 29/01/2016 17:06, Alex Bennée wrote:
> 
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 28/01/2016 11:15, Alex Bennée wrote:
>>> +/* atomic_mb_read/set semantics map Java volatile variables. They are
>>> + * less expensive on some platforms (notably POWER & ARM) than fully
>>> + * sequentially consistent operations.
>>> + *
>>> + * As long as they are used as paired operations they are safe to
>>> + * use. See docs/atomic.txt for more discussion.
>>> + */
> 
> The original comment mentioned both POWER and ARM so I wondering if we
> should also special case for the ARMv7?

I don't know the exact feature test, and I think ARMv7's penalty is much
less because processors are slower, with a less deep pipeline and
usually not used in SMP configurations.

In fact, because it doesn't have "dmb st" and friends, the generated
code should be exactly the same for ARMv7.  Looking at
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html confirms this.

> I think we are OK because if cmpxchg succeeds _old was by definition
> what was already there but it is confusing and leads to funny code like
> this:
> 
>     if (atomic_cmpxchg(&data[i].n, 0, 3) == 0) {
>         data[i].ret = -ECANCELED;
>         ...
> 
> and
> 
>     if (atomic_cmpxchg(&s->state, old_state, new_state) == old_state) {
>        ...
> 
> Which might be easier to read if atomic_cmpxchg used the bool
> semantics, i.e. return true for a successful cmpxchg.

It depends.  When s->state is bool, the bool version is *very* hard to
read.  Then you have two bools and you never know which one it is.  For
example if the expected value is false, atomic_bool_cmpxchg will return
true if the memory location was false...  Aargh! :D

> The old code even has a atomic_bool_cmpxchg which no one seems to use.

Alvise added it, but it's not upstream.

> I wonder if the correct solution is to convert atomic_cmpxchg calls to use
> atomic_cmpxchg_bool calls and remove atomic_cmpxchg from atomic.h?

Yeah, though there are also cases where atomic_cmpxchg_bool is less
efficient.

Not to mention that I don't like the name...  Perhaps atomic_cmpxchg
should be the bool one and atomic_fetch_cmpxchg should return the value.
 Separate patch series though.

Paolo

  reply	other threads:[~2016-02-04 12:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 10:15 [Qemu-devel] [PATCH v1 0/5] ThreadSanitizer support Alex Bennée
2016-01-28 10:15 ` [Qemu-devel] [PATCH v1 1/5] configure: introduce --extra-libs Alex Bennée
2016-01-28 11:14   ` Paolo Bonzini
2016-01-28 11:38     ` Alex Bennée
2016-01-28 10:15 ` [Qemu-devel] [PATCH v1 2/5] configure: ensure ldflags propagated to config_host Alex Bennée
2016-01-28 11:10   ` Paolo Bonzini
2016-01-28 11:13   ` Paolo Bonzini
2016-01-29 15:26     ` Alex Bennée
2016-01-28 10:15 ` [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions Alex Bennée
2016-01-28 11:00   ` Paolo Bonzini
2016-01-29 16:06     ` Alex Bennée
2016-02-04 12:40       ` Paolo Bonzini [this message]
2016-02-04 13:00         ` Peter Maydell
2016-04-01 14:30   ` James Hogan
2016-04-01 14:51     ` Peter Maydell
2016-04-01 16:06     ` Alex Bennée
2016-04-01 20:35   ` Pranith Kumar
2016-04-04  8:14     ` Paolo Bonzini
2016-04-04 16:26       ` Pranith Kumar
2016-04-04 17:03         ` Paolo Bonzini
2016-04-04 20:15           ` Paolo Bonzini
2016-04-05  3:35           ` Pranith Kumar
2016-04-05 12:47             ` Paolo Bonzini
2016-01-28 10:15 ` [Qemu-devel] [PATCH v1 4/5] async.c: various atomic fixes for tsan Alex Bennée
2016-01-28 10:45   ` Paolo Bonzini
2016-01-28 10:15 ` [Qemu-devel] [PATCH v1 5/5] thread-pool: atomic fixes from tsan Alex Bennée
2016-01-28 10:44   ` Paolo Bonzini

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=56B346A2.6050707@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=alex.bennee@linaro.org \
    --cc=fred.konrad@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=mttcg@greensocs.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 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).