22 Oct
2012
22 Oct
'12
2:34 a.m.
Hi
With some threads running on different CPU,
accessing a shared pointer (in RAM) atomically (with gcc atomic methods)
my current understanding is:
- each cpu has its own cache line
- which is updated on every atomic read/write operation
1. is that applicable ?
2. is there a faster or more convenient method, such as
storing the pointer in fast register shared among different cpu ?
--
E.R.
22 Oct
22 Oct
3:18 a.m.
On Mon, 2012-10-22 at 02:34 +0200, Emanuel Rumpf wrote:
Hi
With some threads running on different CPU,
accessing a shared pointer (in RAM) atomically (with gcc atomic methods)
my current understanding is:
- each cpu has its own cache line
- which is updated on every atomic read/write operation
1. is that applicable ?
If everyone is reading, updates are not necessary, so this is fast.
Writes are the problem because they can invalidate the cache of other
CPUs/cores.
2. is there a faster or more convenient method, such
as
storing the pointer in fast register shared among different cpu ?
On CPUs, not really. The cache is transparently controlled by the
hardware (though GPUs and some other weird chips do have explicit shared
cache).
There are shared levels of cache (on multi-core chips), it's just slower
than L1. General registers are not shared.
(Sometimes volatile can have surprising performance effects on shared
variables, if you're playing around and benchmarking, but it doesn't
really guarantee anything).
-dr
31 Oct
31 Oct
9:04 p.m.
On 22/10/12 01:34, Emanuel Rumpf wrote:
Hi
With some threads running on different CPU,
accessing a shared pointer (in RAM) atomically (with gcc atomic methods)
my current understanding is:
- each cpu has its own cache line
- which is updated on every atomic read/write operation
1. is that applicable ?
2. is there a faster or more convenient method, such as
storing the pointer in fast register shared among different cpu ?
Depends on how you design your data structures and on the specific platform.
On x86 reads and writes of pointers are atomic so you won't ever end up
with the corrupt pointer, but you may end up with a stale one. This may
be, or may not be a problem, depending on your use and design, and there
are ways of designing things around it. If applicable to your use case.
If your data structures and their use require locking, which you would
like to avoid, there is a concept called Read-Copy-Update which is for
example heavily used in the kernel and is also available as an userspace
library (http://lttng.org/urcu).
Tvrtko
9:34 p.m.
If your data structures and their use require locking,
which you would like
to avoid, there is a concept called Read-Copy-Update which is for example
heavily used in the kernel and is also available as an userspace library
(http://lttng.org/urcu).
Yes, the RCU approach is quite effective. However, better to not call
it that since IBM has a patent on it last I checked.
-- Paul
1 Nov
1 Nov
8:56 a.m.
Paul Giblock wrote:
Calling it by a different name won't prevent it from infringing IBM
patents.
However, IBM's RCU license for all (L)GPL projects will.
Anyway, that library is published by the patent holder.
Regards,
Clemens
If your data
structures and their use require locking, which you would like
to avoid, there is a concept called Read-Copy-Update which is for example
heavily used in the kernel and is also available as an userspace library
(http://lttng.org/urcu).
Yes, the RCU approach is quite effective. However, better to not call
it that since IBM has a patent on it last I checked.
4188
days inactive
4198
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
5 participants
participants (5)
-
Clemens Ladisch -
David Robillard -
Emanuel Rumpf -
Paul Giblock -
Tvrtko Ursulin