On Tue, Nov 13, 2012 at 6:11 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> > Il 05/11/2012 06:38, Liu Ping Fan ha scritto: >> > > From: Liu Ping Fan <pingf...@linux.vnet.ibm.com> >> > > >> > > If out of global lock, we will be challenged by SMP in low level, >> > > so need atomic ops. >> > > >> > > This file is a wrapper of GCC atomic builtin. >> > >> > I still object to this. >> > >> > I know it enforces type-safety, but it is incomplete. It doesn't >> >> Although it is incomplete, but the rest cases are rarely used. Linux >> faces such issue, and the "int" version is enough, so I think we can >> borrow experience from there. > > One of the two places that use __sync_* require 64-bit accesses. My Yes, these two places are not easy to fix.
> RCU prototype required pointer-sized access, which you cannot make type- But I think that your RCU prototype should rely on atomic of CPU, not gcc‘s atomic. Otherwise, it could be slow (I guess something like spinlock there). Regards, pingfan > safe without C++ templates. > >> > provide neither atomic accesses to pointers, nor useful operations such >> > as exchange. It won't be used consistently, because in some places you >> > just do not have an Atomic value (see both current uses of __sync_* >> > builtins). >> > >> > If you can make it complete, and prove it by using it where >> > __sync_* is >> >> For current code, __sync_* is used rarely, I think except the >> barriers, only two places use it. We can substitute it easily. > > No, you cannot. See above, one doesn't use ints and the other is > guest state so migration becomes complicated if you use Atomic. I'm > happy to be proven wrong, however. > > Paolo
