When I see “I boost system performance X times faster by using Y cache”
Cache is hard
There are only two hard things in Computer Science: cache invalidation and naming things.
- - Phil Karlton
When we work with cache, it brings performance, but it also brings problems. the biggest problem is — data consistency.
Let’s walk it through with interview details.
Story#1 — cache in the small world
Many candidates are not aware there is a cache at the CPU level.
“You mentioned here fixed a critical issue in multi-threading code, could you explain what was that?”.
“Sure, I volatile my variable which is shared across multi-threads.”. he answered.
“So what is the value type of this volatile, and why are you using it”?
“It is an integer, to make sure all threads can get the updated value of the variable”, he said.
“Do you know the cost of using it? And could you pls explain why it works?”.
“I’m not sure about it, it just works. without volatile, multiple threads seeing different values,” he said.
Actually, he was not wrong, I just want to dig into more to touch the limit (was a senior role of C#).
“Do you know about CPU cache? And could you tell me what’s the difference between volatile and lock keywords?”.
“I guess using volatile could be faster”, he said.
we discussed something else.
don’t get me wrong, I am good with the answer.
In this post, we just to discuss more.
Cpu level cache
When we work in multi-threading code, to ensure thread safety(automatic operation), we use locks or synchronized keywords. under the hood, it uses semaphore or mutex.
In case you are not familiar with semaphore, you can check this post and in case you want to have a general idea about the difference between threading and processing or coroutine, you can check here.
Let’s move on and see a thread race condition problem.