process scheduling order is generally unpredictable

Here is a program to demonstrate that operating systems' process schedulers are somewhat whimsical. Given a set of processes a scheduler will run them in some order. Given the same set again, it may, typically, run them in a different order. (It all depends on the scheduler's algorithm. Different schedulers have different algorithms.) For experimentation we have a "multifork.c" source file that can spawn a set of processes.

You could do this exercise on 1) the remote server, 2) your own local linux machine, or 3) a linux virtual machine I may have distributed to you (probably easiest).

To get the file:

 1) on the remote server: it is in the /home/public directory. Log in to the server and get a copy of it into your home directory by

cp  /home/public/multifork.c   ~

 2) on a local linux machine: pull a copy of it from the remote server onto your local machine and work there instead by

scp  public@<server's name>:multifork.c  .     (don't overlook the dot; you will have to give the password given in class  for the server's user account named "public")

 3) on a virtual machine: it may be located in in /home/public. Log in to the VM and and get a copy of it into your home directory by

cp  /home/public/multifork.c   ~

Once you have it you can compile it

gcc  multifork.c  -o  multifork

Read the explanatory comment block at the top of the source file first. 

head  multifork.c     [note: the "head" command shows the first 10 lines of a text file, containing the comment of interest in this case ]

Then run multifork as described there. Suitable commands for you to supply as an argument to it might be /bin/echo, with multiple text token arguments for echo processes to print, or /bin/ls, with multiple (existing) file names for ls processes to list. Supply five or six arguments. Suitable invocations might be these two:

./multifork   /bin/echo   one   two   three   four   five     [note: the dot-slash in front of the "multifork" command directs the shell to look for the multifork executable in the current directory]

 launches the following five as separate processes:
  /bin/echo  one  [which prints "one"]
  /bin/echo  two  [which prints "two"]
  /bin/echo  three  [which prints "three"]
  /bin/echo  four  [which prints "four"]
  /bin/echo  five  [which prints "five"]

./mutifork   /bin/date   +%A   +%B   +%Y   +%d

 launches the following four as separate processes:
  /bin/date  +%A   [which prints current day-of-the-week]
  /bin/date  +%B   [which prints current month-of-the-year]
  /bin/date  +%Y   [which prints current year]
  /bin/date  +%d   [which prints current date-of-the-month]

The scheduling order is at the discretion and whim of the particular job scheduler that runs on your platform. A scheduler might run a largely identical set of processes in one order the first time, and a different order the next. That's what this program shows on the platforms I have tried. Can I necessarily rely on it work same way (varying order) on your unix system?

Homework instructions:
If this exercise is assigned as homework, please run one of the above two invocations of multifork at least three times and study the output. Produce a screenshot showing your several invocations and their results, three or more of them on the screen. Name the screenshot file "multifork.jpg (or .png)"and upload it.