atomic operations in user space

[Esben Nielsen]

On Tue, 29 Aug 2006, Li Yang wrote:

>> This is exactly how it is supposed to work! That's why there is a loop
>> in the atomic increment - you check if you still had the reservation
>> after the transaction by checking the result from the stwcx, and if not,
>> retry.
>
> I surely know all the theories you mentioned clearly.  But please do
> look at the case I gave.  Correct me if I missed anything.  Thanks
>
> All the lwarx and stwcx operate on the same address.
>
>> Task A		Task B
>> lwarx
> // Get RESERVATION
>> 			......
>> 			lwarx
>> 			stwcx
>
> // RESERVATION cleared
>>
>> 			.....
>> 			.....
>> 			lwarx
>
> // Get RESERVATION again

Now we do a task switch involving atomic operations, and thus an 
reservation on another address.

>> stwcx
>
> //Note here: RESERVATION is valid, address is the same.
> So the result is commited, no retry for task A
>
>> .....
>> 			stwcx
> //RESERVATION is cleared, retry atomic op for task B
>
> Please be noted that reservation is only identified by reservation bit
> and address operated on.  So different lwarx's on the same address,
> may be considered as the same reservation.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>