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, I would probably strongly > > prefer the Java formulation. > > Awesome answer, and this last paragraph sums it up pretty well.
I disagree that for non-Java code the Java model should be better. Both C11 and C++11 use the same model, and I don't see a reason to not use it if you're writing C/C++ code anyway. The C++ model is definitely useful for practitioners; just because it uses seq-cst memory order as safe default doesn't mean that programmers that can deal with weaker ordering guarantees can't make use of those weaker ones. I thought Paul was referring to seq-cst as default; if that wasn't the point he wanted to make, I actually don't understand his theory/practice comparison (never mind that whenever you need to reason about concurrent stuff, having a solid formal framework as the one by the Cambridge group is definitely helpful). Seq-cst and acq-rel are just different guarantees -- this doesn't mean that one is better than the other; you need to understand anyway what you're doing and which one you need. Often, ensuring a synchronized-with edge by pairing release/acquire will be sufficient, but that doesn't say anything about the Java vs. C/C++ model. > That was basically my understanding, too. I still do not completely > get the relationship between Java semantics and ACQ_REL, but I can > sidestep the issue for adding portable atomics to QEMU. QEMU > developers and Linux developers have some overlap, and Java volatiles > are simple to understand in terms of memory barriers (which Linux > uses); hence, I'll treat ourselves as pure practitioners. 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 also allow you to just point to the C11 model and any information / tutorials about it instead of having to document your own (see the patch), and you can make use of any (future) tool support (e.g., race detectors). > I will just not use __atomic_load/__atomic_store to implement the > primitives, and always express them in terms of memory barriers. Why? (If there's some QEMU-specific reason, just let me know; I know little about QEMU..) I would assume that using the __atomic* builtins is just fine if they're available. Torvald
