When I said that the OS executes the processes in time slots, I was not absolutely precise. Every process has one or more threads, and threads are executed. A thread is the smallest execution managed by an external scheduler. Older operating systems did not have the notion of a thread and were executing processes. As a matter of fact, the first thread implementations were simply duplications of processes that were sharing the memory.

You may hear the terminology, lightweight process—it means a thread.

The important thing is that the threads do not have their own memory. They use the memory of the process. In other words, the threads that run in the same process have undistinguished access to the same memory segment. It is an extremely powerful possibility to implement parallel algorithms that make use of the multiple cores in the machine, but at the same time, it may lead to bugs.

Imagine that two threads increment the same long variable. The increment first calculates the incremented value of the lower 32 bits and then the upper, if there were any overflow bits. These are two or more steps that may be interrupted by the OS. It may happen that one thread increments the lower 32 bits, remembers that there is something to do to the upper 32 bits, starts the calculation, but has no time to store the result before it gets interrupted. Then, another thread increments the lower 32 bits, the upper 32 bits, and then the first thread just saves the upper 32 bits that it calculated. The result gets garbled. On an older 32-bit Java implementation, it was extremely easy to demonstrate this effect. On a 64-bit Java implementation, all the 64 bits are loaded into registers and saved back to the memory in one step so it is not that easy to demonstrate multithread issues, but it does not mean that there are none.

When a thread is paused and another thread is started, the operating system has to perform a context switch. It means that, among other things, the CPU registers have to be saved and then set to the value that they should have for the other thread. A context switch is always saving the state of the thread and loading the previously saved state of the thread to be started. This is on a CPU register level. This context switch is time consuming; therefore, the more context switches that are done, the more CPU resource is used for the thread administration instead of letting them run. On the other hand, if there are not enough switches, some threads may not get enough time slots to execute, and the program hangs.