From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33256)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1b326j-0001zg-G5
	for qemu-devel@nongnu.org; Wed, 18 May 2016 10:05:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1b326d-0006bk-9k
	for qemu-devel@nongnu.org; Wed, 18 May 2016 10:05:53 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33144)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1b326d-0006be-4L
	for qemu-devel@nongnu.org; Wed, 18 May 2016 10:05:47 -0400
References: <1463196873-17737-1-git-send-email-cota@braap.org>
	<1463196873-17737-8-git-send-email-cota@braap.org>
	<573B5134.8060104@gmail.com> <20160517193842.GB30174@flamenco>
	<573B80AD.50503@gmail.com> <20160517231809.GA17517@flamenco>
	<573C7536.7080104@gmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <3c729264-24c0-e3f4-2cdd-62afb47f80e1@redhat.com>
Date: Wed, 18 May 2016 16:05:34 +0200
MIME-Version: 1.0
In-Reply-To: <573C7536.7080104@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v5 07/18] qemu-thread: add simple
 test-and-set spinlock
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Sergey Fedorov <serge.fdrv@gmail.com>, "Emilio G. Cota" <cota@braap.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, MTTCG Devel <mttcg@greensocs.com>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, Peter Crosthwaite <crosthwaite.peter@gmail.com>, Richard Henderson <rth@twiddle.net>



On 18/05/2016 15:59, Sergey Fedorov wrote:
>=20
> But actually (cf include/qemu/atomic.h) we can have:
>=20
>     #define atomic_read(ptr)                              \
>         ({                                                \
>         QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
>         typeof(*ptr) _val;                                \
>          __atomic_load(ptr, &_val, __ATOMIC_RELAXED);     \
>         _val;                                             \
>         })
>=20
>=20
> I can't find anywhere if this __atomic_load() has volatile/compiler
> barrier semantics...

The standard says "you can have data races on atomic loads", that is
very close to compiler barrier semantics but indeed atomics.txt should
be updated to explain the C11 memory model in not-so-formal terms.

For example this:

  atomic_set(&x, 1);
  atomic_set(&y, 1);
  atomic_set(&x, 2);
  atomic_set(&y, 2);

could become

  atomic_set(&x, 2);
  atomic_set(&y, 2);

with C11 atomics but not with volatile.  However this:

  if (atomic_read(&x) !=3D 1) {
    atomic_set(&x, 1);
  }

couldn't become an unconditional

  atomic_set(&x, 1);

Thanks,

Paolo