On Wed, 2019-10-02 at 15:20 +0200, Paolo Bonzini wrote:
> On 02/10/19 13:05, Jan Glauber wrote:
> > The arm64 code generated for the
> > atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> > memory barriers. It is just plain ldaxr/stlxr.
> >
> > From my understanding this is not
On Thu, 2013-06-20 at 09:53 +0200, Paolo Bonzini wrote:
Il 19/06/2013 22:25, Torvald Riegel ha scritto:
On Wed, 2013-06-19 at 17:14 +0200, Paolo Bonzini wrote:
(1) I don't care about relaxed RMW ops (loads/stores occur in hot paths,
but RMW shouldn't be that bad. I don't care if reference
On Tue, 2013-06-18 at 18:53 -0700, Paul E. McKenney wrote:
On Tue, Jun 18, 2013 at 05:37:42PM +0200, Torvald Riegel wrote:
On Tue, 2013-06-18 at 07:50 -0700, Paul E. McKenney wrote:
First, I am not a fan of SC, mostly because there don't seem to be many
(any?) production-quality
On Wed, 2013-06-19 at 11:31 +0200, Paolo Bonzini wrote:
Il 18/06/2013 18:38, Torvald Riegel ha scritto:
I don't think that this is the conclusion here. I strongly suggest to
just go with the C11/C++11 model, instead of rolling your own or trying
to replicate the Java model. That would
On Wed, 2013-06-19 at 17:14 +0200, Paolo Bonzini wrote:
Il 19/06/2013 15:15, Torvald Riegel ha scritto:
One reason is that implementing SC for POWER is quite expensive,
Sure, but you don't have to use SC fences or atomics if you don't want
them. Note that C11/C++11 as well
On Thu, 2013-06-20 at 04:59 +0800, Liu Ping Fan wrote:
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index fbabf99..28abe1e 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -16,6 +16,7 @@
#include sys/ioctl.h
#include hw/virtio/vhost.h
#include hw/hw.h
+#include
On Tue, 2013-06-18 at 15:24 +0200, Paolo Bonzini wrote:
Il 17/06/2013 20:57, Richard Henderson ha scritto:
+ * And for the few ia64 lovers that exist, an atomic_mb_read is a ld.acq,
+ * while an atomic_mb_set is a st.rel followed by a memory barrier.
...
+ */
+#ifndef atomic_mb_read
On Tue, 2013-06-18 at 18:08 +0200, Paolo Bonzini wrote:
Il 18/06/2013 16:50, Paul E. McKenney ha scritto:
PS: Nevertheless, I personally prefer the C++ formulation, but that is
only because I stand with one foot in theory and the other in
practice. If I were a pure practitioner,
On Tue, 2013-06-18 at 07:50 -0700, Paul E. McKenney wrote:
First, I am not a fan of SC, mostly because there don't seem to be many
(any?) production-quality algorithms that need SC. But if you really
want to take a parallel-programming trip back to the 1980s, let's go! ;-)
Dekker-style
