RE: atomic operations in user space

3 messages, 2 authors, 2006-08-29 · open the first message on its own page

RE: atomic operations in user space

From: Li Yang <hidden>
Date: 2006-08-29 13:37:57

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

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.

RE: atomic operations in user space

From: Esben Nielsen <hidden>
Date: 2006-08-29 16:06:02


On Tue, 29 Aug 2006, Li Yang wrote:

quoted

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.

quoted

Task A		Task B
lwarx

// Get RESERVATION

quoted

			......
			lwarx
			stwcx

// RESERVATION cleared

quoted

			.....
			.....
			lwarx

// Get RESERVATION again

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

quoted

stwcx

//Note here: RESERVATION is valid, address is the same.
So the result is commited, no retry for task A

quoted

.....
			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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: atomic operations in user space

From: Li Yang <hidden>
Date: 2006-08-29 17:00:37

On 8/30/06, Esben Nielsen [off-list ref] wrote:


On Tue, 29 Aug 2006, Li Yang wrote:

quoted

quoted

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.

quoted

Task A               Task B
lwarx

// Get RESERVATION

quoted

                     ......
                     lwarx
                     stwcx

// RESERVATION cleared

quoted

                     .....
                     .....
                     lwarx

// Get RESERVATION again

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

This makes sense for me.