atomic operations in user space

[Brent Cook]

> -----Original Message-----
> From: 
> linuxppc-embedded-bounces+bcook=bpointsys.com at ozlabs.org 
> [mailto:linuxppc-embedded-bounces+bcook=bpointsys.com at ozlabs.o
rg] On Behalf Of Li Yang-r58472
> Sent: Tuesday, August 29, 2006 5:53 AM
> To: Esben Nielsen; Liu Dave-r63238
> Cc: Xupei Liang; linuxppc-embedded at ozlabs.org
> Subject: RE: atomic operations in user space
> 
> > It is available for PowerPC, but not in POWER and POWER2
> instructionsets
> > according to 
> http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
> > It is the same in the ARM world: Atomic instructions was 
> introduced in
> > ARMv6 I believe. Older ARM processors don't have them.
> 
> Yes, I do know there are lwarx and stwrx instructions.  But 
> there is only one reservation per CPU and reservation can be 
> re-established with no difference.
> So there are possibilities reservation is broken and reserved 
> again in one atomic block.
> 
> Task A			Task B
> lwarx
> 				......
> 				lwarx
> 				stwrx
> 
> 				.....
> 				.....
> 				lwarx
> stwrx
> .....
> 				stwrx
> 
> The addresses of above operations are the same.
> 
> In this case Thread A thinks that it is atomic as it holds 
> the same reservation, but it is actually broken.  Such 
> control flow can't be prevented in user space.
> 

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. This works perfectly well no matter if it is from userspace or
the kernel - it is a CPU function. It even works between CPUs on some
later PowerPCs - I've had it working perfectly from userspace on a dual
7448 setup.

PowerPC atomic instructions are not atomic in the sense that they _lock_
anything. The only thing these instructions give you is a way to see if
another thread used the instructions while your thread was using them,
and if you see a conflict, you retry until your code finishes
uninterrupted. This makes it fine for short transactions, like atomic
increment. You probably would not want to use these instructions for
protecting longer transactions of more than a few instructions.

If you look at how, for instance, futexes work in Linux, they rely on
being able to do atomic increment and decrement from _userspace_.

Read this article to understand how it works:
http://www-128.ibm.com/developerworks/library/pa-atom/

 - Brent