Conflicts memory access in case simultaniusly work two cores?

[Jun_T_1]

Hello.

I have a question about inter-core contention for multicore CPUs.

There is code that looks like this, for two CPU cores core1 and core2:

When executed at the same time, and does not reset the bit to be reset.
Is that possible?

core1:
mov rbx, 0x00500000
or [rbx + 0x10], 0x00010000

core2:
mov rbx, 0x00500000
mov eax, [rbx + 0x10]
and eax, 0xfffdffff; ; 0xfffdffff = = ~ 0x00020000
mov [rbx + 0x10], eax

where 0x00500010 is 0x00200000 should be reset but remains set.

The background to this question is that there is an exclusive control bug in some of our code.
It behaved as if the bit was not reset.
The code should have looked like this:.

core1:
mov rbs, 0x00500000
lock()                            ;; Some form of locking, such as a semaphore.
or [rbx + 0x10], 0x00010000
unlock()

core2:
mov rbx, 0x00500000
lock()
mov rax, [rbx + 0x10]
and rax, ~ 0x00020000
mov [rbx + 0x10], rax
unlock()

Addionary, i am using the Xeon E5-2658 v2 (IvyBridge).

Regards,

[McCalpinJohn]

I can't tell exactly what it is you are trying to do, but ordering of visibility of operations in multiprocessor systems is quite tricky, and many cases need some form of explicit serialization.

Chapter 8 of Volume 3 of the Intel Architectures SW Developer's Manual (document 325384-071) discusses these issues, particularly in Section 8.2, with Section 8.2.3 providing many useful examples.

It can be helpful to realize that the concept "at the same time" is not applicable in cache-coherent multiprocessor systems -- all that can be discussed is the order in which stores become visible to other cores.  The examples in Section 8.2.3 may be helpful.   

I have found the presentation in "A Primer on Memory Consistency and Cache Coherence" (https://doi.org/10.2200/S00346ED1V01Y201104CAC016) to be very helpful because of the consistency of the language used to describe the various consistency models. There is also a newer version of the book (https://doi.org/10.2200/S00962ED2V01Y201910CAC049), but I have not had a chance to look at it yet....

[Jun_T_1]

John,

Thank you for your comment. I will check the SDM Vol.3 Chap.8 again, also I will read suggested URLs.
And, I will test our code after fix out bug.

Thank you.