From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50461)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bumsK-0005V9-0U
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 16:45:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bumsE-0006E8-2f
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 16:45:10 -0400
Received: from mx4-phx2.redhat.com ([209.132.183.25]:46106)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bumsD-0006DX-OZ
	for qemu-devel@nongnu.org; Thu, 13 Oct 2016 16:45:06 -0400
Date: Thu, 13 Oct 2016 16:45:00 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <891420528.3270107.1476391500461.JavaMail.zimbra@redhat.com>
In-Reply-To: <20161013192015.GA22617@flamenco>
References: <1476107947-31430-1-git-send-email-pbonzini@redhat.com>
	<1476107947-31430-3-git-send-email-pbonzini@redhat.com>
	<20161013192015.GA22617@flamenco>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 2/5] cpus: use atomic_read to read
 seqlock-protected variables
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: "Emilio G. Cota" <cota@braap.org>
Cc: qemu-devel@nongnu.org, alex bennee <alex.bennee@linaro.org>

> Is tsan happy with the way seqlocks are written right now?

I honestly don't know.  But if there are tsan bugs there's
not much we can do.  The alternative below has overhead on
ARM and PPC and does not quite fit in atomic.h.

In any case, a bigger issue is that this patch breaks on
32-bit because it does 64-bit atomic_read.  We might have
to fall back to volatile when not running on tsan.

Paolo

> Dmitry Vyukov wrote:
> > 1. Tsan is bad at handling stand-alone memory barriers.
> > And here is a way to express seqlock that is both correct, is
> > understood by tsan and is no overhead on x86:
> > 
> > // writer
> > atomic_store(&seq, seq+1, memory_order_relaxed);
> > atomic_store(&data[0], ..., memory_order_release);
> > ...
> > atomic_store(&data[N], ..., memory_order_release);
> > atomic_store(&seq, seq+1, memory_order_release);
> > 
> > // reader
> > atomic_load(&seq, memory_order_acquire);
> > d0 = atomic_load(&data[0], memory_order_acquire);
> > ...
> > dN = atomic_load(&data[N], memory_order_acquire);
> > atomic_load(&seq, memory_order_relaxed);
> 
> Source: https://groups.google.com/forum/#!topic/thread-sanitizer/B4i9EMQ4BQE
> 
> Thanks,
> 
> 		Emilio
>