> -----Original Message----- > From: Esben Nielsen [mailto:nielsen.esben at gogglemail.com] > Sent: Tuesday, August 29, 2006 5:57 PM > To: Liu Dave-r63238 > Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang; linuxppc-embedded at ozlabs.org > Subject: RE: atomic operations in user space > > > > On Tue, 29 Aug 2006, Liu Dave-r63238 wrote: > > >>> 2) These mutexes are based on futexes which requires atomic > >>> operations in userspace. These are available on most architectures. > > Look at > >>> the glibc code in > >>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance. > >>> Use that and your PPC manual to implement your atomic operations. > >> > >> No matter semaphore or futex, it uses system calls to kernel. > > There is only a system call if there is congestion - that is the whole idea > behind the futex. > > >> And the > >> true atomic operation is in kernel not user space. > > "True" atomic operations are available in user space on most architectures. > > >> Maybe > >> it's feasible > >> for other architectures to do atomic operations directly in > >> user space. > >> IMHO, not for powerpc. > > 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. > > > > > Are you meaning that we didn't do atomic operations directly in user > > space > > on powerpc platform ? > > > > Well, that is not the conclusion I get either when reading the glibc code. > Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h. > > This is by the way probably what the original post in this thread wanted > in the first place! > > Esben > > > > -DAve