M**********n
发帖数: 432 | 1 I have the following statement in a function in one thread.
a = b;
Both a and b are 4-byte global variables. Now I have another thread that is
reading variable a too.
Is the above assignment atomic in x86_64?
If not, when the assignment resumes execution, will the stale b value (b
could have already been changed) or the updated b value be assigned to a? |
p***o
发帖数: 1252 | 2 What do you mean by atomic? Do you know memory barrier?
is
【在 M**********n 的大作中提到】
: I have the following statement in a function in one thread.
: a = b;
: Both a and b are 4-byte global variables. Now I have another thread that is
: reading variable a too.
: Is the above assignment atomic in x86_64?
: If not, when the assignment resumes execution, will the stale b value (b
: could have already been changed) or the updated b value be assigned to a?
|
M**********n
发帖数: 432 | 3 By non-atomic/atomic, I mean the assignment may be not completely finishged
before the context is switched to another thread.
【在 p***o 的大作中提到】
: What do you mean by atomic? Do you know memory barrier?
:
: is
|
d******e
发帖数: 2265 | 4 make sure b is volatile socit is not cached in register
is
【在 M**********n 的大作中提到】
: I have the following statement in a function in one thread.
: a = b;
: Both a and b are 4-byte global variables. Now I have another thread that is
: reading variable a too.
: Is the above assignment atomic in x86_64?
: If not, when the assignment resumes execution, will the stale b value (b
: could have already been changed) or the updated b value be assigned to a?
|
w***g
发帖数: 5958 | 5 问单个赋值操作是不是atomic没有意义。连续若干个读写操作才会有atomic或者memory
barrier的问题。
is
【在 M**********n 的大作中提到】
: I have the following statement in a function in one thread.
: a = b;
: Both a and b are 4-byte global variables. Now I have another thread that is
: reading variable a too.
: Is the above assignment atomic in x86_64?
: If not, when the assignment resumes execution, will the stale b value (b
: could have already been changed) or the updated b value be assigned to a?
|
M**********n
发帖数: 432 | 6 Thanks
【在 d******e 的大作中提到】
: make sure b is volatile socit is not cached in register
:
: is
|
M**********n
发帖数: 432 | 7 It matters to us since we need lokc-free concurrency.
We need to make sure that when the assignment occurs (no matter atomic or
non-atomic in that sense), the latest and updated value of b is used in the
assignment.
memory
【在 w***g 的大作中提到】
: 问单个赋值操作是不是atomic没有意义。连续若干个读写操作才会有atomic或者memory
: barrier的问题。
:
: is
|
p***o
发帖数: 1252 | 8 You need to understand memory barrier in order to implement your own
lock-free code.
the
【在 M**********n 的大作中提到】
: It matters to us since we need lokc-free concurrency.
: We need to make sure that when the assignment occurs (no matter atomic or
: non-atomic in that sense), the latest and updated value of b is used in the
: assignment.
:
: memory
|
M**********n
发帖数: 432 | 9 Thanks. I am not familiar with memory barrier. Just took a quick look at the
wiki page.
We don't care how compiler or CPU reordering the instructions.
All we care is that when that assignment is executed, the value assigned to
a is the value retrieved from b's actual memory address instead of some temp
register. Can this be guaranteed?
【在 p***o 的大作中提到】
: You need to understand memory barrier in order to implement your own
: lock-free code.
:
: the
|
M**********n
发帖数: 432 | 10
Here is the illustration of a and b in two threads.
Thread 1 only writes to b and read a.
Thread 2 only writes to a and read b.
Thread 1 execution:
b = -1;
b = 0;
b = 1;
if(a != 0)
{
//do this
}
Thread 2 execution:
a = b;
// do that
Question is this:
Can the if condition be satisfied in thread 1 and 0 is assigned to a in
thread 2 (assuming a is initialized to -1 before both threads are started)?
【在 p***o 的大作中提到】
: You need to understand memory barrier in order to implement your own
: lock-free code.
:
: the
|
|
|
p***o
发帖数: 1252 | 11 Sure, why not ...
1 For Thread 2, a=b can be compiled into two instructions.
2 Even if you can make a=b a single instruction, compiler/processor
can reorder the writes to b and reads from a in Thread 1.
Here is the book if you have time to read:
Is Parallel Programming Hard, And, If So, What Can You Do About It?
Otherwise try to find a library instead of writing your own code.
【在 M**********n 的大作中提到】
:
: Here is the illustration of a and b in two threads.
: Thread 1 only writes to b and read a.
: Thread 2 only writes to a and read b.
: Thread 1 execution:
: b = -1;
: b = 0;
: b = 1;
: if(a != 0)
: {
|
m**********s
发帖数: 518 | 12 On 32bit machine, the assignment is atomic.
If both threads run on same cpu core, nothing to worry about.
However, if it's multi core, the read thread potentially run on another core
might still see stale "a" due to lack of memory barrier. You need to ask
for sync to achieve lock free.
Hope this helps.
By non-atomic/atomic, I mean the assignment may be not completely finishged
before the c........
【在 M**********n 的大作中提到】
: By non-atomic/atomic, I mean the assignment may be not completely finishged
: before the context is switched to another thread.
|
w***x
发帖数: 105 | 13 thread 1 execution:
try this:
b = -1;
smp_wb();
b = 0;
smp_wb();
b = 1;
smp_wb();
if(ACCESS_ONCE(a) != 0)
{
//do this
}
Thread 2 execution:
a = b;
smp_mb();
// do that |
M**********n
发帖数: 432 | 14 Thanks.
We have loads/assignments between these instructions that serve as memory
barrier already. If compiler reorder these instructions, it will break
single thread logic.
[发表自未名空间手机版 - m.mitbbs.com]
【在 w***x 的大作中提到】
: thread 1 execution:
: try this:
: b = -1;
: smp_wb();
: b = 0;
: smp_wb();
: b = 1;
: smp_wb();
: if(ACCESS_ONCE(a) != 0)
: {
|
w***x
发帖数: 105 | 15 mb/rb include both compiler memory barrier & cpu barriers. |
r***s
发帖数: 737 | 16 All "lock free" concurrency are implemented using atomic instructions
such as compare and swap, which use memory barrier to ensure safety.
It is non-sensible that you use lock free concurrency without
understanding memory barrier. Even if you get this one right you would
make other serious mistakes somewhere else.
Usually compilers won't allocate registers across instructions that
carries memory barrier behavior. However sometimes compiler may get
confused because of programmer's mistake. For example, if your
variable has an alias, and that alias is assigned to a temp variable
you are doomed either way.
the
【在 M**********n 的大作中提到】
: It matters to us since we need lokc-free concurrency.
: We need to make sure that when the assignment occurs (no matter atomic or
: non-atomic in that sense), the latest and updated value of b is used in the
: assignment.
:
: memory
|
z*******3
发帖数: 13709 | 17 不一定
immutable一样可以满足lock free concurrency的需要
不过这贴我没看上下文，你们继续
【在 r***s 的大作中提到】
: All "lock free" concurrency are implemented using atomic instructions
: such as compare and swap, which use memory barrier to ensure safety.
: It is non-sensible that you use lock free concurrency without
: understanding memory barrier. Even if you get this one right you would
: make other serious mistakes somewhere else.
: Usually compilers won't allocate registers across instructions that
: carries memory barrier behavior. However sometimes compiler may get
: confused because of programmer's mistake. For example, if your
: variable has an alias, and that alias is assigned to a temp variable
: you are doomed either way.
|
r***s
发帖数: 737 | 18 I strongly suggest you give up your efforts and find someone to help you
No. Loads and assignments don't serve as memory barrier.
They can either be served
From cache or even registers. With multi core the chance
Of your code run as you expected is near 0
The topic of concurrent programming is a complex one and clearly
You don't even know the basics.
【在 M**********n 的大作中提到】
: Thanks.
: We have loads/assignments between these instructions that serve as memory
: barrier already. If compiler reorder these instructions, it will break
: single thread logic.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
