Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is processor cache flushed during context switch in multicore?

Recently, I discussed why there is a volatile mark at seq in Java Actors demo

@volatile private var seq = 0L
private def nextSeq: Long = {
  val next = seq
  seq += 1
  next
}

One answer was that threads can be migrated and variables lost (other cores will have incoherent values in their private caches). But, you not normally mark every variable with volatile to enable multicore execution. So, cores must flush the caches whenever context is switched. But, I cannot find this statement pronounced explicitly anywhere. Everybody, eg. Wikipedia, only care about registers and stack memory

The state of the process includes all the registers that the process may be using, especially the program counter, plus any other operating system specific data that may be necessary. This data is usually stored in a data structure called a process control block (PCB), or switchframe. In order to switch processes, the PCB for the first process must be created and saved. The PCBs are sometimes stored upon a per-process stack in kernel memory (as opposed to the user-mode call stack), or there may be some specific operating system defined data structure for this information.

What do we have in reality regarding migrating the general purpose data/variables?

like image 206
Val Avatar asked Jun 11 '15 07:06

Val


1 Answers

Whenever there is any sort of context switch the OS will save its state such that it can be restarted again on any core (assuming it has not been tied to a specific core using a processor affinity function).

Saving a state that for some reason or other is incomplete defeats the entire purpose of threading or processing, therefore the caches are flushed as part of the switch.

Volatile has nothing whatsover to do with context switching. It merely tells the compiler that the memory location is subject to change without notice and therefore must be accessed each time the source code dictates it i e the usual compiler behaviour of optimizing accesses to memory locations does not apply to the volatile-declared location.

like image 189
Olof Forshell Avatar answered Dec 07 '22 22:12

Olof Forshell