Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.06.17 at 19:21, <andre.przywara@xxxxxxx> wrote:
> On 14/06/17 10:12, Jan Beulich wrote:
>>>>> On 13.06.17 at 17:25, <andre.przywara@xxxxxxx> wrote:
>>> @@ -0,0 +1,116 @@
>>> +Atomic operations in Xen
>>> +========================
>>> +
>>> +Data structures in Xen memory which can be accessed by multiple CPUs
>>> +at the same time need to be protected against getting corrupted.
>>> +The easiest way to do this is using a lock (spinlock in Xen's case),
>>> +that guarantees that only one CPU can access that memory at a given point
>>> +in time, also allows protecting whole data structures against becoming
>>> +inconsistent. For most use cases this should be the way to go and 
>>> programmers
>>> +should stop reading here.
>> 
>> As further down you talk about lockless approaches only, please
>> also mention r/w write locking above.
> 
> What do you mean with "r/w write locking" here? Does Xen's rwlock_t use
> some lockless tricks?

No. My comment was about you mentioning spin locks, but not r/w
locks.

>>> +What ACCESS_ONCE does *not* guarantee though is this access is done in a
>>> +single instruction, so complex or non-native or unaligned data types are
>>> +not guaranteed to be atomic. If for instance counter would be a 64-bit 
>>> value
>>> +on a 32-bit system, the compiler would probably generate two load 
>>> instructions,
>>> +which could end up in reading a wrong value if some other CPU changes the 
>>> other
>>> +half of the variable in between those two reads.
>>> +However accessing _aligned and native_ data types is guaranteed to be 
>>> atomic
>>> +in the architectures supported by Xen, so ACCESS_ONCE is safe to use when
>>> +these conditions are met.
>> 
>> As mentioned before, such a guarantee does not exist. Please only
>> state what is really the case, i.e. we _expect_ compilers to behave
>> this way.
> 
> Do you mean the guarantee of using a single machine instruction to
> access variables?
> For the "aligned access to native data types" there are explicit
> architectural guarantees:
> Intel manual volume 3, chapter 8.1.1 Guaranteed Atomic Operations
> ARMv7 ARM, chapter A3.5.3  Atomicity in the ARM architecture
> ARMv8 ARM, chapter B2.6.1  Requirements for single-copy atomicity
> (I will probably add those references to the document anyway)

Sure, once the compiler emits what we hope for, all is fine. But once
again - the compiler is not required to do so, and hence there's no
such guarantee.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel