Process – let’s start concurrency

Process – let’s start concurrency

Reading Time: ~ 6 minutes

Ahhh a process… the stuff I need. THE thing to run on!

Hey guys, here I am, the master of concurrency! In this post I briefly want to discuss what processes are, what are they for, and answer all the necessary questions to serve as a base from our further explorations of the Concurrency world.

What is a process?

You see, when you start your computer and the OS gets booted, not everything is all beautifully placed and ready to go, as if you would just buy a nice picture and hang it in your wall.

hanging a picture of the OS

Stuff needs to be loaded, pixels need to be painted and all those programs your Mother installed on your computer while she was just trying to “check her email”, start running on the background.

But they don’t “just” start out of nothing. There is a concept behind it, the most central concept in any OS: the Process!

process is an abstraction of a running program. Without it, basically the modern computer could not exist. It has the ability to transform a single core processor into a (virtual-) multi-core processor and thus allow for “parallel” execution.

It is important to understand that a process is NOT a program. To make this clearer let’s use a quick analogy:

Ted is a father and DIYer. He is trying to build a skateboard for his kid and has everything he need there: the wheels, the deck, the trucks and the tools. Ted also has the instruction manuals, which he is following.

In this situation we have:

  • Instructions – is just like the program, i.e. an algorithm explaining what should happen.
  • Skateboard parts – are the inputs to this program.
  • Ted – as the CPU.
  • The process is the activity where Ted reads the instructions, gets the parts and assembles them with his tools.

A process has…

Some necessary information to start with and keep track of what it is doing throughout its execution. These usually contains:

Everything a process is carrying around

  • the program itself, in executable machine code format
  • some memory (virtual) which has:
    • input and output data
    • a call stack, to keep track of subroutines
    • a heap to hold data generated at runtime
  • File descriptors and links
  • Security attributes, such as process owner
  • Processor state!

The power of process

Ok, imagine this scenario:

  • You can’t run anything in parallel
  • One process at a time ONLY (!) in the CPU (Single Core)

Other than your worst nightmare, this is how this would play out:

Boot your computer and wait… Wait more… Just a bit more. Now the PC is up and you click on free cell to get your game on. Everything freezes while the computer is fetching the resources from disk. You literally cannot do anything else… Oh and of course, there is nothing running on the background, so don’t worry about incoming emails and such.

Maybe a good thing in that scenario would be that, even viruses wouldn’t be able to do anything in the background. But of course they would take complete control once they get to execute… ok… maybe not so good.

Due to the existence of the process, we don’t have to suffer through this. We can enjoy the magic of parallelism, even if we are on a single CPU machine (which is starting to become rare nowadays. Yey progress!)

Switching and Scheduling

This parallelism we’ve been talking about, is achieved due to the CPU’s capability of switching and scheduling every process. The CPU allocates a bit of time for every process and cycle through them. By doing so more than one thing can happen “at the same time”. Because this happens so fast, we perceive it as parallel. This is of course made possible due to the process which carries its info around and knows where to pick it up from.

For the CPU some tasks take AGES! The CPU is so fast that a request from data from the hard-drive it is just too long to keep waiting for, so it goes to another task and schedules to come back to the data when it is available.

CPU's don't wait for anybody

Now since this post is not about processors, I won’t go into much more detail, however if there is a desire for it (comment away) I would create a post about it. But just for the sake of re-using my analogy from before and to show how switching would fit in that, here we go:

Ted is working on building the longboard. Suddenly his kid comes crying because he tripped and fell on his knees. Ted stops the building of the longboard and switches his attention to his kid. Once he calmed the kid down and she goes to play again, Ted switches back to the task of the building.

States and transitions of a process

Possible states of a process
Taken from []
As you can see, there are several different states in which we can find a process in. I will quickly go through each state and explain what it means.

  1. Created – This is a newborn process. It keeps waiting admission to the “waiting” state so it can play with the other big boys 😉
  2. Waiting (Ready) – The process is ready to be executed. It is in-memory and just waiting for the CPU to give it some time to work. There are usually many processes in this state.
  3. Running – This state means the process is running, i.e. the CPU allocated time for it in a core (1 Core = 1 process)
  4. Blocked – In this state the process cannot go on. This might be because it expects a user input, or it is waiting for an I/O Device or even waiting to execute a section of critical code in which just one process is allowed at a time.
  5. Terminated – The process was finished, either by coming to an end or forcefully. Although it is terminated it will stay in the process table a while.


The other two states are similar to the described but just due to a lack of memory they might have been moved to the swap space (which is a bit slower). To find a short explanation about the topic of process states check the wikipedia page for it.

Types of processes

Finally, there are some different names you might hear a process being called. Here are a few:

  • Parent/Child – One process can create one or more other processes. When it does, one can refer to them as parent and child, for the creator and the creations respectively.
  • Daemon – this is a process which runs in the background without the control of an interactive user
  • Zombie – It is when a process is on its terminated state but still on the process table. This occurs only to child processes and the parent has to actually read the child’s terminated state before this can be discarded
  • Orphan – If the parent of a process is terminated (or terminates) but the child is still running, we call it an orphan.


Want to know more?

If you want to know more about processes, I recommend a book on operational systems. Here are two of them that I really enjoyed:

Leave your opinion, start a discussion, share an experience or just a compliment...

%d bloggers like this: