CITS2002 Systems Programming  

Unit home

Final exam


Lecture & Workshop
recordings on LMS



C textbooks

OS textbooks

Information resources

Extra reading

Past projects

Recent feedback

Working effectively

Look after yourself!

Project 1 Clarifications - see also project description and marking rubric

This page provides any clarifications, more detailed explanations, big hints, or corrects any errors identified after the project description was released. This page will be updated with responses to any common problems or misunderstandings posted on help2002 or asked in laboratory sessions.

14th September
When being marked on a standard Linux platform, your project will be compiled and linked with the command:

prompt> cc -std=c11 -Wall -Werror -o myscheduler myscheduler.c -lm

(the project may use standard-C11 libraries, which include the mathematical functions).

Your total execution time (on the measurements line) should be within a range of the sample solution's time T. If a test (a sequence of commands) involves a total of S system-calls, and your project requires an extra 1usec for each (worst case??), we'll be marking with a tolerance/range of T +/- S usecs. Please read - help2002.

7th September
Please read - Where does that 'extra' usec come from for each system-call?

6th September
If a process calls the 'wait' system-call when it has no children, it should be moved from the CPU to the READY queue (not to the WAITING queue).

4th September

A process remains on the CPU (computing something) until:

  • it calls exit, RUNNING→EXIT (0 usecs).
  • it calls any blocking system-call, RUNNING→BLOCKED (10 usecs).
  • its time-quantum expires, RUNNING→READY (10 usecs). Process that exhaust their time-quantum always return to the READY queue.
When the CPU is idle (no process or the OS is using the CPU), perform the following in this order:
  1. unblock any sleeping processes
  2. unblock any processes waiting for all their spawned processes (children) to terminate
  3. unblock any completed I/O
  4. commence any pending I/O
  5. commence/resume the next READY process
  6. otherwise the CPU remains idle...

If multiple processes can be unblocked at any time, they are unblocked (added to the READY queue) in the same order that they requested their action.

The revised sample solution schedules the processes by following this order, performs some basic checks on its input files (which you do not have to replicate), and its debug output (which you do not have to replicate) is more descriptive of what is happening.

You may download the shellscript that allows you to run the sample solution from your shell's command-line, rather than requiring a web-browser:

  1. download the shellscript
  2. make it executable:
    prompt> chmod +x ./
  3. run:
    prompt> ./  sysconfig-file  command-file
    prompt> ./  -v  sysconfig-file  command-file

26th August
The very first process (spawned from the first command in the commands file) should be added to the READY queue (NEW→READY), and then moved to the CPU (READY→RUNNING).

25th August
Some help2002 threads that you should read:

24th August
When spawing a new process:
  • create the new (child) process
  • append the new process to the READY queue (NEW→READY)
  • append the current (parent) process to the READY queue (RUNNING→READY)
In following this sequence, the new (child) process will run before its parent.
The parent process does not have to call wait (if it doesn't want to wait for the new child process).


Chris McDonald.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Presented by [email protected]