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?
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?
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
f*j
14 楼
我看很多直播都会不断loading,然后有时候就退出了, 会是因为我的网络速度不够吗?
d*e
15 楼
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?
【在 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
18 楼
Thanks
【在 d******e 的大作中提到】 : make sure b is volatile socit is not cached in register : : is
M*n
19 楼
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
20 楼
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
21 楼
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
22 楼
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
23 楼
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
24 楼
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
25 楼
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
26 楼
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.
mb/rb include both compiler memory barrier & cpu barriers.
r*s
28 楼
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
【在 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
30 楼
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]