Multi threading could cause a racing condition if two threads are accessing the same memory slot, but why is that? From a HW point of view, if the two cores are designed the same, internal pipelines are the same, the logic gates/transistors pass electrons the same way and the speed of those electrons is a constant value then what causes the race?
Theoretically speaking shouldn't the two threads access the memory slot at the exact same time down to the nano second, every time?
Your understanding of computer hardware is flawed. Memory is not accessed by different cores in parallel, access is regulated like traffic at a road junction. Different threads can run simultaneously on different cores but they do not access the same memory cell together. What can happen is one thread ruining the work of another thread, like overwriting a result value before it has been read by a consumer. But that would be done sequentially, threads do not "collide", hitting the same cell at the same time. Reads and writes are all performed in a very controlled manner.
The race conditions software engineers speak of are not a thing at the transistor level. They are a thing at the much higher program logic level.
Think using a boolean value to control access to a resource. Before one thread uses the resource it checks the value to find it is false, meaning the resource is available. So it sets the value to true, signaling to other threads the resource is now occupied, and continues to use the resource. Between the check and set operation however another thread could have checked the value and also have found it to be false. This is the race and the unpredictability. Yet access to the variable by both threads was all performed sequentially in the most orderly fashion.
So we need something better than a boolean variable to regulate traffic at the software level and this can only work with hardware support. This problem cannot be solved in software alone. Modern processors support this feature, we most often call this a lock.
This is a great question! There's several factors here:
Firstly,
the logic gates/transistors pass electrons the same way and the speed of those electrons is a constant value
This isn't the case. At the high switching speeds of modern chips, and with just how fast electricity flows, nothing is ever perfectly synchronized. (As an aside, electricity isn't the flow of one electron pushing the next, like a tube of marbles. It's complicated) This is why digital chips rely on a clock. A clock synchronizes everything within its clock domain so that everything runs just a little slower than the slowest thing in the clock domain.
The fundamental issue with threading is that you're almost always going to want more software threads than you can concurrently execute on your hardware. If this weren't the case, then every disk read or network request would be needlessly stalling your CPU and wasting its opportunity to do other work. To mitigate this, you have a kernel that's responsible for scheduling ready-to-run threads onto the CPU, and switching between them rapidly enough to give the illusion of true parallelism.
The "race" comes from the unpredictability of the scheduling of threads. At any point, the kernel might decide "that's enough from you, give others a chance", and preempt your thread. You can imagine this as if you had a call to anyOtherThreadCanRunNow() between every single line of your program. Worse-yet, this preemption doesn't happen on the boundary between one line of high-level code and the next, but between every single instruction your program compiles to.
The difficulty comes from the combination of:
Theoretically speaking shouldn't the two threads access the memory slot at the exact same time down to the nano second, every time?
Theoretically speaking is fine unless you want to build something real. Build something based on that theory and you’ve just created a very troublesome requirement for anything those threads do.
If nanosecond synchronization across threads is required then you have a problem with file IO, cache misses, or indeed any kind of OS or hardware interrupt. Unless you make all threads wait together they’re going to get out of sync.
Even the task itself can cause trouble. Two threads doing the same work, with the same instructions, but different input, can cause one thread to experience an error that it needs to recover from. Again you’d have to force the threads to wait together to stay in sync.
So you could do this but what’s the point? That’s a lot of work and wasted cycles just because you don’t want to think about avoiding race conditions.
Even if you pushed for this really hard and spread this paranoia as far as you could, eventually you’d be talking with something outside this control, and be facing the same problem all over again.
So please stop blindly= checking if a file exists before writing to it. Even if it did you still have no right to expect it to exist now. Just write and find out if it does. Yes it feels weird to think this way. But this is how it works. No magic wand is going to keep us from needing to think this way. Just get used to it.
Because the hard- and software is optimized for efficiency, not predictability.
For instance:
When designing the HW of a computer, the designers need to consider a variety of properties, and determinism is only one of them. Other properties include efficiency, throughput, ...
In the embedded world, with very small micro-processors, you may indeed find chips (& boards) which are fairly deterministic, though more as a result of absence of sophistication, than by design.
In the mobile/desktop/server world, efficiency and throughput have long been prioritized over determinism:
So, even without touching on (1) Cache Coherency Protocols and (2) Software, as you can see, modern computers have a lot of source of differences between their various cores.
shouldn't the two threads access the memory slot at the exact same time down to the nano second, every time
What you are describing here is something much, much worse than a race condition - you are describing contention. Contention is when two different circuits are trying to drive the same output at the same time.
Imagine the two cores are trying to write to a bit. Think of that bit as a wire. The first core is trying to write a 1 and the second core is trying to write a 0. For the sake of simplicity let's assume a positive logic convention and a CPU core running at 1.2 volts. What happens to that wire when one of the cores is trying to drive that wire to 1.2v and the other core is trying to drive that wire to 0v?
Well, in terms of hardware design we say the value of that bit is unpredictable and in simulation software it will be marked with a value of "x" instead of "1", "0", "z" or "?" (true, false, high-impedence, unknown). But let's say we ignore a hardware designer's sensibilities and the warnings of circuit simulators. What is physically happening to that wire?
Practically anything can happen. The details depend on the exact design of the circuit and what type of transistor you are using to drive the output and even the position of stars in the sky (not literally but kind of true - everything from cosmic rays to the earth's magnetic field can have a tiny effect).
But let's say we design the circuit in such a way as to be stable in this case and not affected by silly things like the state of the universe. For simplicity let's make the circuit behave like a perfect voltage divider if a part of it is equally being sourced some voltage and is sinking voltage. So the value of the wire is 0.6v. If 1.2v has a value of 1 and 0v has a value of 0 what is the digital (binary) value of 0.6v?
What happens in the real world is that the memory cell will have a cut-off value of what it considers 1 and what it considers 0. Let's say for the sake of simplicity our memory cell interprets anything lower than 0.6v as the value 0 and 0.6v and higher as the value of 1. So in theory if both cores is trying to write different values to memory the result should be 1 right? So is it that simple to solve?
Unfortunately no. Due to manufacturing defects that 0.6v cut-off is not exactly 0.6v. Some cells will have a cut-off at 0.6000001. Some will have a cut-off at 0.59999999 some will have a cut-off at 0.602311 etc. So in effect you cannot predict what the value will be in memory when two cores are trying to write different values to the same variable.
But let's say we can design a circuit to safely solve the unpredictability. It's actually quite simple. We can combine the outputs of both circuits using something like an OR gate. So it is solved? In terms of hardware yes. In terms of how a programmer expects the CPU to behave no.
Consider the two cores are trying to write two different values to the same variable:
Thread 1 is trying to write the character "P"
Thread 2 is trying to write the character "F"
The binary value for "P" is 01010000 and the binary value of "F" is 01000110. This results in the value in memory becoming "V":
01010000 = P
or 01000110 = F
-----------
01010110 = V
I assume the programmer who wrote the program does not expect the value "V" at all. I'd personally expect the variable to contain the value "P" or "F" and no other value. Isn't this a bug? I'd consider this a form of data corruption!
Because of this very weirdly unexpected behavior, no real hardware will allow two source to have write access to the same memory at the same time (read access is no problem - we do this all the time with dual-ported memory in GPUs allowing the GPU to read the memory in parallel with the CPU). Generally the CPU will be designed so that only one source will have write access to the same area of memory.
There are many different techniques a hardware designer can use to select which source can access the memory. These techniques (algorithms) are generally called "arbitration". The simplest is to simply have a default priority: eg. core0 will always go first, core1 will go next etc.
While the root cause of a race condition is real-world timing and thus is a kind of hardware problem, the reason we experience it is not a hardware issue. If we know for a fact that there is a priority of which core gets to write a value to the same variable first and which one gets to write next we can design our logic to take this into account.
The problem is we don't write our software to run on CPUs. We write them to run on Operating Systems and the operating system we use will automatically allocate our threads to run on separate cores. So when we write our code, we don't know which thread gets to write to the variable first - and that fact of not knowing is the crux of the problem with race conditions.
When you asked this question you talk about CPU design and why they cause race conditions. The fact is, in the real world the timing problem does not involve the CPU at all.
Let's look at an example: say you are trying to download some data from two servers: SERVER_A and SERVER_B. For the sake of simplicity let's assume we are trying to get a list of IP addresses from a Bittorrent cloud.
SERVER_A has very good low latency. Pings to it respond almost immediately. So we connect to SERVER_A first and get a response from it first.
SERVER_B has bad high latency and takes a longer to respond to the connection. However, SERVER_B has a very high speed connection so even though SERVER_A answers first SERVER_B completes sending all the data before SERVER_A.
Assume SERVER_A sends:
22.44.1.2
128.77.0.43
Assume SERVER_B sends:
34.2.66.7
34.2.131.17
Assume we write our software without thinking about race conditions and write each response directly to file as they arrive. Because SERVER_A sends the response first the file will probably begin with 22. but because SERVER_A is slow the file will also end with .43 instead of .17!
So potentially the file could look something like:
22.434.24..61.62
7
34.21.28..131.107
.43
Instead of:
22.44.1.2
128.77.0.43
34.2.66.7
34.2.131.17
This is because of the race condition where SERVER_B's response is received while we are processing SERVER_A's response.
You can see that in this case the race condition has nothing to do with the CPU design or even your motherboard's design but is related to real-world timing. Quite literally a race condition bug is when a programmer forgets that his software runs in the real world where things are not as predictable as expected.
Take a processor with a single core. There is a timer which fires say 100 times a second, and when it fires, the operating system decides whether to switch from one thread to another. That is about the simplest implementation of pre-emptive multithreading. (There is also co-operative multithreading which is totally different and not much in use anymore).
Most likely the timer is not 100% precise. When it fires after 10 milliseconds, the number of instructions performed by a thread is not guaranteed to be the same. The timer can be controlled by a different clock than the processor, so it doesn't always fire after the same number of clock cycles.
Now I move the mouse while the program is running. This will cause an interrupt, so your thread stops running while the mouse movement is being processed. But the timer fires at the same time, so after executing fewer instructions.
Now I have a processor that protects the computer from excessive heat by slowing down if it gets hot. But the timer isn't affected by this. My computer performs 2.0 instead of 3.0 billion instructions per seconds, so 20 instead of 30 million instructions between the timer firing twice.
Now I have a laptop with a battery. When the battery goes low it reduces the clock speed. Guess what happens.
That's just a few things that make it quite unpredictable what exactly happens. And if you look at Matthieu M.'s answer, he has a similar list but from the other end of your computer (deeply internal things instead of external influences).
The best way to think about this question is a 'what happens if' excercise:
What happens if we have a memory system which allows 2 separate CPUs to make accesses simultaneously, without delaying either access in any case. An 'access' in this case being either a read or a write of a single memory location, and the storage for each location is independent. Simultaneous access will fall into one of the following categories:
So we can produce some rules about how this memory should behave, the same behaviour can be produced by arbitrating the accesses and delaying one access, which is probably simpler electronically.
We also haven't removed the 'race condition'. Races happen when changes to the relative execution timing affect observed behaviour. While computers do have (in general) deterministic timing, in most real world conditions we cannot rely on it. In the cases I've described above, one access happening a single cycle earlier can change either the final value stored in memory, or the value read by a different CPU.
When talking about multi-threading code, we are implicitly talking about preemptive multitasking. This means that there is some supervisory process running on the computer that can halt the execution of a thread at any time for any amount of time. Given this environment, it is impossible to make any statements about the relative execution time of CPU instructions on different threads. The only statement you can make is that the instructions execute in order for a single thread (and for modern CPU designs that's only a guarantee as far as externally visible behaviour goes)
