|
|
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
-
CLARIFICATION OF SCHEDULING ORDER
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:
- unblock any sleeping processes
- unblock any processes waiting for all their spawned processes (children) to terminate
- unblock any completed I/O
- commence any pending I/O
- commence/resume the next READY process
- 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
run-myscheduler-solution.sh
that allows you to run the sample solution from your shell's
command-line, rather than requiring a web-browser:
- download the shellscript
- make it executable:
prompt> chmod +x ./run-myscheduler-solution.sh
- run:
prompt> ./run-myscheduler-solution.sh sysconfig-file command-file
or:
prompt> ./run-myscheduler-solution.sh -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.
|
