Official website for Linux User & Developer
FOLLOW US ON:
Apr
6

Process synchronisation in Linux

by Swayam Prakasha

The two fundamental concepts in a Linux operating system are processes and time slice. A process is an instance of a program that is being executed by the computer’s operating system. When we say that two computers are communicating with each other, we mean that two processes, one running on each computer, are in communication with each other.

The two fundamental concepts in a Linux operating system are processes and time slice. A process is an instance of a program that is being executed by the computer’s operating system. When we say that two computers are communicating with each other, we mean that two processes, one running on each computer, are in communication with each other. The only way a new process can be created by the Linux system is by issuing the fork() system call. We need to understand here that system calls are the entry points through which an active process can obtain the services from the kernel.

Linux operates on the principle of time slice – every single process is given a little bit of time for its execution. If the process execution is not completed, then it will be put in a suspended mode till it gets its time slice and after that it continues its execution. The switch between different processes happens so fast that an end user will never be able to visualise it.

Let us explain the time slice concept with an example – assume that there are two processes and Linux gives each a time slice of two seconds. When two seconds elapse for the first process, it is moved into the swap area. Now the second process starts to execute. Once its two seconds are over, it will be moved into the swap area. The first process will be reloaded and its execution begins. This switch happens every two seconds until one of the processes finishes.

Let us see how we can create new processes by using fork() system call:

#include<stdio.h>
main()
{
fork();
printf(“Hello, this is a test program\n”);
}

fork - example code

The above is a simple example with only two lines of code (Fig 1 above). After compiling and executing the above program, we can see that the statement ‘Hello, this is a test program’ will be displayed twice (Fig 2 below).

fork output display

Pages: 1 2 3 4 5 6 7 8
  • Tell a Friend
  • Follow our Twitter to find out about all the latest Linux news, reviews, previews, interviews, features and a whole more.
    • kdm

      A few points worth making, should anyone actually try to write programs using 1003.1 calls:

      1. It is technically incorrect to call non-async signal safe routines (ie. almost anything in the C library) after a fork(), but before exec().
      This is how deadlocks can be created, as your child process _could_ still be holding a mutex (for example, in the memory allocator). This can be particularly nasty in multi-threaded programs. I have fixed this bug in production code on several occasions.

      2. lockf()/fcntl()/file locking is useless. It doesn’t work on NFS volumes, and is unreliable anyway, so please don’t bother to suggest it. There _are_ schemes with lock files that can be atomic, however.

      To quote from the relevant man page:
      “The solution for performing atomic file locking using a lockfile is to create a unique file on the same filesystem (e.g., incorporating hostname and pid), use link(2) to make a link to the lockfile and use stat(2) on the unique file to check if its link count has increased to 2. Do not use the return value of the link(2) call.”

    • Rainer Weikusat


      1. It is technically incorrect to call non-async signal safe routines (ie. almost anything in the C library) after a fork(), but before exec().

      UNIX(*) is a superset of C and the set of UNIX(*) routines which are async-signal
      safe is much larger than the set of C library routines. Also, the statement above
      is theoretically only true for multithreaded processes and practically only
      relevant insofar locks are actually being held across fork.


      2. lockf()/fcntl()/file locking is useless. It doesn’t work on NFS volumes, and is unreliable anyway, so please don’t bother to suggest it.

      fcntl locks are not unreliable and they do work on NFS, minus halfway mythical
      problems with unknown rpc.lockd-implementations which reportedly existed on some
      nameless set of UNIX(*) platforms more than fifteen years ago. Personally, I doubt
      if these problems ever existed and weren’t just invented by people unwilling to
      let go of their habitual dot-locking hackery.