With multitasking being the norm these days, modern operating systems need to deal with more than one processes. As such, your operating system kernel already provides primitives for writing concurrent programs in one of the following forms:

• Processes: In this approach, we can run different parts of a program by spawning separate replicas of themselves. On Linux, this can be achieved using the fork system call. To communicate any data with the spawned processes, one can use various Inter Process Communication (IPC) facilities such as pipes and FIFOs. Process based concurrency provides you with features such as fault isolation, but also has the overhead of starting a whole new process. There's a limited number of processes you can spawn before the OS runs out of memory and kills them. Process-based concurrency is seen in Python's multiprocessing module.
• Threads: Processes under the hood are just threads, specifically called the main thread. A process can launch or spawn one or more threads. A thread is the smallest schedulable unit of execution. Every process starts with a main thread. In addition to that, it can spawn additional threads using the APIs provided by the OS. To allow a programmer to use threads, most languages come with threading APIs in their standard library. They are lightweight compared to processes. Threads share the same address space with the parent process. They don't need to have a separate entry in the Process Control Block (PCB) in the kernel, which is updated every time we spawn a new process. But taming multiple threads within a process is a challenge because, unlike processes, they share the address space with their parent process and other child threads and, because scheduling of threads is decided by the OS, we cannot rely on the order the threads will execute and what memory they will read from or write to. These operations suddenly become hard to reason about when we go from a single-threaded program to a multi-threaded one.