Historically, all computer programs were written in an utterly sequential fashion.
This is simple to read, write, and understand.
Its also simple for a computer to execute and requires relatively simple hardware.
Increasing code efficiency may be possible, but it is generally a complex process with often limited results.
For decades, performance could be decreased by waiting for new, more efficient CPUs.
As described by Moores law, CPUs roughly double in performance every two to three years.
Unfortunately, most of these performance gains came from using ever-smaller manufacturing nodes.
To get around this, modern CPU architects have opted to add multiple processor cores to CPUs.
Each processor core can act independently on a different task.
While they cant combine the same problem, they can work on two issues simultaneously.
To take advantage of multi-core CPUs, code must be written in a multi-threaded fashion.
Doing this, though, runs into a new challenge, the race condition.
Note:Some tasks cant be multi-threaded, while others can be massively multi-threaded.
The possible performance benefits do rely on the work being done.
Contents
Race Conditions
Multi-threaded software can take advantage of multiple cores.
Dangers are lurking in those waters, ready to trap the inexperienced programmer.
A race condition can occur when two different threads interact with the same bit of memory.
A simple example could be two threads trying to check and increment a variable simultaneously.
Two different threads then perform their functions and, at some point, checkaand increment it by one.
Generally, youd expect the result of two threads adding one to zero to be two.
Most of the time, this should be the case.
In this case, the first thread reads the value ofa.
Before the first thread can increment the value ofathough, the second thread reads it.
The result of this is that the final value ofais 1, not 2.
What if the value ofaselects the mode of operation of a machine?
What if specific modes of operation of that machine can be dangerous or even life-threatening?
Race conditions also dont need to be that simple.
Lets say that the check is a simple true/false check.
This isnt true or false.
Not being either of the two options in a binary choice would almost certainly result in the app crashing.
This memory corruption can lead to many security issues, such as denial of service and privilege escalation.
Nothing needs to be done if a variable is only ever controlled and accessible by a single thread.
This independence is achieved thanks to a lock.
This lock blocks other threads from accessing that piece of memory until the lock is released.
The lock isnt the most elegant of solutions.
For one thing, it has memory overheads.
It also can force a thread to hang, waiting for a lock to be released.
Its essential to optimize the use of locks.
you’re free to control how granular the lock is.
Locking the whole table would be a coarse granularity lock.
Locking just the row would be a fine granularity lock.
Memory locks come with a memory overhead but can also cause blocking.
