There is another big issue with caches, called cache invalidation. Since, usually, in new processors, you use multithreaded applications, it sometimes happens that one thread changes some information in memory and that the other threads need to check it. As you might know, or as you will see in Chapter 10, Multithreading, Rust makes this perfectly safe at compile time. Data races won't happen, but it won't prevent cache invalidation performance issues.

A cache invalidation happens in the case that some information in the RAM gets changed by another CPU or thread. This means that if that memory location was cached in any L1 to L3 caches, somehow it will need to be removed from there, since it will have old values. This is usually done by the storage mechanism. Whenever a memory address gets changed, any cache pointing to that memory address gets invalidated. This way, the next instruction trying to read the data from that address will create a cache miss, thus making the cache refresh and get data from the RAM.

This is pretty inefficient, in any case, since every time you change a shared variable, that variable will require a cache refresh in the rest of the threads it gets used. In Rust, for that, you will be using an Arc. To try to avoid this kind of performance pitfall, you should try to share as little as possible between threads, and if messages have to be delivered to them, it might sometimes make sense to use structures in the std::sync::mpsc module, as we will see in Chapter 10, Multithreading.