Вопрос

I have this question related to memory barriers.

In a multi-threaded applications a memory barrier must be used if data is shared between them , because a write in a thread that is runing on one core , may not be seen by another thread on an another core.

From what I read from other explanations of memory barriers, it was said that if you have a single thread working with some data you don't need a memory barrier.

And here is my question: it could be the case that a thread modifies some data on a specific core, and then after some time the scheduler decides to migrate that thread to another core.

Is it possible that this thread will not see its modifications done on the other core?

Это было полезно?

Решение

In principle: Yes, if program execution moves from one core to the next, it might not see all writes that occurred on the previous core.

Keep in mind though that processes don't switch cores by themselves. It is the operating system that preempts execution and moves the thread to a new core. Thus it is also the operating system's responsibility to ensure that memory operations are properly synchronized when performing a context switch.

For you as a programmer this means that, as long as you are not trying work on a level where there is no SMP-aware OS (for instance, when you are trying to write your own OS or when working on an embedded platform without a fully-fledged OS), you do not need to worry about synchronization issues for this case.

Другие советы

The OS is responsible of memory coherency or visibility in additonal to memory ordering after a thread migration. a.k.a, below test always passes:

int a = A
/* migration here */
assert(a == A)
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top