I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
Regards,
Terry Liang
-----Original Message-----
From: Brent Cook [mailto:bcook at bpointsys.com]
Sent: Thursday, August 24, 2006 10:18 PM
To: linuxppc-embedded at ozlabs.org
Cc: Li Yang-r58472; Terry Liang
Subject: Re: atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
quoted
Why do you need atomic operations in user land?
IPC will be
sufficient
quoted
to deal with race conditions between processes.
quoted
quoted
Best Regards,
quoted
Leo
What about multiple threads within a process
updating a counter?
Is there anything preventing semaphore to be used in
threads?
Of course, if you look at these functions in the
kernel header,
they're just 2 or
3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
increment' and grab one of the unencumbered
implementations if you
need to use it
in a non-GPL program.
On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
file at all, same for PowerPC - are Linux header
files actually GPL or
are they
more like the glibc headers, with exceptions made
for userspace
programs?
The atomic operations on x86 were accidentally
exported early on, so
they have to
hang around apparently for compatibility (there are
some mailing list
threads out
there to this effect.) Currently, you just have to
assume in Linux
that if you
include something from /usr/include/linux or asm
that it will not
necessarily be
cross-version or cross-architecture compatible. Not
every arch in
Linux even has
atomic operations of this nature, which I guess is
the main reason why
they are
not exported in general.
- Brent
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-----Original Message-----
From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
Xupei Liang
Sent: Tuesday, August 29, 2006 8:44 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: atomic operations in user space
=20
I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
Atomic operations are working under strict restrictions. Generally they
won't work for user space. Your best bet is to use semaphore instead.
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
=20
Regards,
=20
Terry Liang
=20
=20
quoted
-----Original Message-----
From: Brent Cook [mailto:bcook at bpointsys.com]
Sent: Thursday, August 24, 2006 10:18 PM
To: linuxppc-embedded at ozlabs.org
Cc: Li Yang-r58472; Terry Liang
Subject: Re: atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
quoted
quoted
Why do you need atomic operations in user land?
IPC will be
sufficient
quoted
quoted
to deal with race conditions between processes.
quoted
quoted
Best Regards,
quoted
Leo
What about multiple threads within a process
updating a counter?
=20
Is there anything preventing semaphore to be used in
threads?
quoted
Of course, if you look at these functions in the
kernel header,
they're just 2 or
quoted
3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
quoted
increment' and grab one of the unencumbered
implementations if you
need to use it
quoted
in a non-GPL program.
On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
quoted
file at all, same for PowerPC - are Linux header
files actually GPL or
are they
quoted
more like the glibc headers, with exceptions made
for userspace
programs?
quoted
The atomic operations on x86 were accidentally
exported early on, so
they have to
quoted
hang around apparently for compatibility (there are
some mailing list
threads out
quoted
there to this effect.) Currently, you just have to
assume in Linux
that if you
quoted
include something from /usr/include/linux or asm
that it will not
necessarily be
quoted
cross-version or cross-architecture compatible. Not
every arch in
Linux even has
quoted
atomic operations of this nature, which I guess is
the main reason why
they are
quoted
not exported in general.
- Brent
=20
=20
=20
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
quoted
-----Original Message-----
From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On
Behalf Of
quoted
Xupei Liang
Sent: Tuesday, August 29, 2006 8:44 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: atomic operations in user space
I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
Atomic operations are working under strict restrictions. Generally they
won't work for user space. Your best bet is to use semaphore instead.
Wrong.
1) Semaphores give priority inversions. Use a mutex with priority
inheritance instead. This comes in 2.6.18.
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 forinstance.
Use that and your PPC manual to implement your atomic operations.
Esben
quoted
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
Regards,
Terry Liang
quoted
-----Original Message-----
From: Brent Cook [mailto:bcook at bpointsys.com]
Sent: Thursday, August 24, 2006 10:18 PM
To: linuxppc-embedded at ozlabs.org
Cc: Li Yang-r58472; Terry Liang
Subject: Re: atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
quoted
quoted
Why do you need atomic operations in user land?
IPC will be
sufficient
quoted
quoted
to deal with race conditions between processes.
quoted
quoted
Best Regards,
quoted
Leo
What about multiple threads within a process
updating a counter?
Is there anything preventing semaphore to be used in
threads?
quoted
Of course, if you look at these functions in the
kernel header,
they're just 2 or
quoted
3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
quoted
increment' and grab one of the unencumbered
implementations if you
need to use it
quoted
in a non-GPL program.
On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
quoted
file at all, same for PowerPC - are Linux header
files actually GPL or
are they
quoted
more like the glibc headers, with exceptions made
for userspace
programs?
quoted
The atomic operations on x86 were accidentally
exported early on, so
they have to
quoted
hang around apparently for compatibility (there are
some mailing list
threads out
quoted
there to this effect.) Currently, you just have to
assume in Linux
that if you
quoted
include something from /usr/include/linux or asm
that it will not
necessarily be
quoted
cross-version or cross-architecture compatible. Not
every arch in
Linux even has
quoted
atomic operations of this nature, which I guess is
the main reason why
they are
quoted
not exported in general.
- Brent
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
-----Original Message-----
From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
Sent: Tuesday, August 29, 2006 4:33 PM
To: Li Yang-r58472
Cc: Xupei Liang; linuxppc-embedded@ozlabs.org
Subject: RE: atomic operations in user space
=20
=20
=20
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
=20
quoted
quoted
-----Original Message-----
From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org]
On
quoted
Behalf Of
quoted
Xupei Liang
Sent: Tuesday, August 29, 2006 8:44 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: atomic operations in user space
I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
Atomic operations are working under strict restrictions. Generally
they
quoted
won't work for user space. Your best bet is to use semaphore
instead.
quoted
=20
Wrong.
1) Semaphores give priority inversions. Use a mutex with priority
inheritance instead. This comes in 2.6.18.
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 forinstance.
Use that and your PPC manual to implement your atomic operations.
No matter semaphore or futex, it uses system calls to kernel. And the
true atomic operation is in kernel not user space. Maybe it's feasible
for other architectures to do atomic operations directly in user space.
IMHO, not for powerpc.
=20
Esben
=20
quoted
quoted
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
Regards,
Terry Liang
quoted
-----Original Message-----
From: Brent Cook [mailto:bcook at bpointsys.com]
Sent: Thursday, August 24, 2006 10:18 PM
To: linuxppc-embedded at ozlabs.org
Cc: Li Yang-r58472; Terry Liang
Subject: Re: atomic operations in user space
On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
quoted
quoted
Why do you need atomic operations in user land?
IPC will be
sufficient
quoted
quoted
to deal with race conditions between processes.
quoted
quoted
Best Regards,
quoted
Leo
What about multiple threads within a process
updating a counter?
Is there anything preventing semaphore to be used in
threads?
quoted
Of course, if you look at these functions in the
kernel header,
they're just 2 or
quoted
3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
quoted
increment' and grab one of the unencumbered
implementations if you
need to use it
quoted
in a non-GPL program.
On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
quoted
file at all, same for PowerPC - are Linux header
files actually GPL or
are they
quoted
more like the glibc headers, with exceptions made
for userspace
programs?
quoted
The atomic operations on x86 were accidentally
exported early on, so
they have to
quoted
hang around apparently for compatibility (there are
some mailing list
threads out
quoted
there to this effect.) Currently, you just have to
assume in Linux
that if you
quoted
include something from /usr/include/linux or asm
that it will not
necessarily be
quoted
cross-version or cross-architecture compatible. Not
every arch in
Linux even has
quoted
atomic operations of this nature, which I guess is
the main reason why
they are
quoted
not exported in general.
- Brent
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
quoted
quoted
2) These mutexes are based on futexes which requires atomic
operations in userspace. These are available on most architectures.
Look at
quoted
quoted
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.
quoted
And the
true atomic operation is in kernel not user space.
"True" atomic operations are available in user space on most architectures.
quoted
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.
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
quoted
quoted
quoted
2) These mutexes are based on futexes which requires atomic=20
operations in userspace. These are available on most=20
architectures.
quoted
Look at
quoted
quoted
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.
=20
There is only a system call if there is congestion - that is=20
the whole idea behind the futex.
=20
quoted
quoted
And the
true atomic operation is in kernel not user space.
=20
"True" atomic operations are available in user space on most=20
architectures.
=20
quoted
quoted
Maybe
it's feasible
for other architectures to do atomic operations directly in user=20
space.
IMHO, not for powerpc.
=20
It is available for PowerPC, but not in POWER and POWER2=20
instructionsets according to=20
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.
=20
quoted
Are you meaning that we didn't do atomic operations directly in user
space
on powerpc platform ?
=20
Well, that is not the conclusion I get either when reading=20
the glibc code.
Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
=20
This is by the way probably what the original post in this=20
thread wanted=20
in the first place!
=20
Esben
I totally agree with you and Brant about it. I don't believe we cannot
do the atomic operation in user space on powerpc.
-DAve=20
-----Original Message-----
From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
Sent: Tuesday, August 29, 2006 5:57 PM
To: Liu Dave-r63238
Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
linuxppc-embedded@ozlabs.org
Subject: RE: atomic operations in user space
=20
=20
=20
On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
=20
quoted
quoted
quoted
2) These mutexes are based on futexes which requires atomic
operations in userspace. These are available on most
architectures.
quoted
Look at
quoted
quoted
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.
=20
There is only a system call if there is congestion - that is the whole
idea
behind the futex.
=20
quoted
quoted
And the
true atomic operation is in kernel not user space.
=20
"True" atomic operations are available in user space on most
architectures.
=20
quoted
quoted
Maybe
it's feasible
for other architectures to do atomic operations directly in
user space.
IMHO, not for powerpc.
=20
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.
=20
quoted
Are you meaning that we didn't do atomic operations directly in user
space
on powerpc platform ?
=20
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.
=20
This is by the way probably what the original post in this thread
wanted
in the first place!
=20
Esben
=20
=20
quoted
-DAve
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
quoted
-----Original Message-----
From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
Sent: Tuesday, August 29, 2006 5:57 PM
To: Liu Dave-r63238
Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
linuxppc-embedded@ozlabs.org
quoted
Subject: RE: atomic operations in user space
On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
quoted
quoted
quoted
2) These mutexes are based on futexes which requires atomic
operations in userspace. These are available on most
architectures.
quoted
quoted
Look at
quoted
quoted
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
quoted
behind the futex.
quoted
quoted
And the
true atomic operation is in kernel not user space.
"True" atomic operations are available in user space on most
architectures.
quoted
quoted
quoted
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
quoted
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.
So you are saying that futexes on powerpc are broken?
Esben
quoted
quoted
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.
quoted
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
quoted
in the first place!
Esben
quoted
-DAve
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
On Tue, 29 Aug 2006, Esben Nielsen wrote:
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
quoted
quoted
-----Original Message-----
From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
Sent: Tuesday, August 29, 2006 5:57 PM
To: Liu Dave-r63238
Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
linuxppc-embedded@ozlabs.org
quoted
Subject: RE: atomic operations in user space
On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
quoted
quoted
quoted
2) These mutexes are based on futexes which requires atomic
operations in userspace. These are available on most
architectures.
quoted
quoted
Look at
quoted
quoted
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
quoted
behind the futex.
quoted
quoted
And the
true atomic operation is in kernel not user space.
"True" atomic operations are available in user space on most
architectures.
quoted
quoted
quoted
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
quoted
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.
So you are saying that futexes on powerpc are broken?
Are you sure the reservation isn't automaticly broken due to the task
switch?
Esben
Esben
quoted
quoted
quoted
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.
quoted
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
quoted
in the first place!
Esben
quoted
-DAve
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
-----Original Message-----
From:=20
linuxppc-embedded-bounces+bcook=3Dbpointsys.com@ozlabs.org=20
[mailto:linuxppc-embedded-bounces+bcook=3Dbpointsys.com@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@ozlabs.org
Subject: RE: atomic operations in user space
=20
quoted
It is available for PowerPC, but not in POWER and POWER2
instructionsets
quoted
according to=20
http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
quoted
It is the same in the ARM world: Atomic instructions was=20
introduced in
quoted
ARMv6 I believe. Older ARM processors don't have them.
=20
Yes, I do know there are lwarx and stwrx instructions. But=20
there is only one reservation per CPU and reservation can be=20
re-established with no difference.
So there are possibilities reservation is broken and reserved=20
again in one atomic block.
=20
Task A Task B
lwarx
......
lwarx
stwrx
=20
.....
.....
lwarx
stwrx
.....
stwrx
=20
The addresses of above operations are the same.
=20
In this case Thread A thinks that it is atomic as it holds=20
the same reservation, but it is actually broken. Such=20
control flow can't be prevented in user space.
=20
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