Skip to main content
Mathematics LibreTexts

7.2: Getting Started

  • Page ID
    34212
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    To begin thinking about scheduling, let us consider an auto shop that is converting a car from gas to electric. A number of steps are involved. A time estimate for each task is given.

    • Task 1: Remove engine and gas parts (2 days)
    • Task 2: Steam clean the inside of the car (0.5 day)
    • Task 3: Buy an electric motor and speed controller (2 days for travel)
    • Task 4: Construct the part that connects the motor to the car’s transmission (1 day)
    • Task 5: Construct battery racks (2 days)
    • Task 6: Install the motor (0.5 day)
    • Task 7: Install the speed controller (0.5 day)
    • Task 8: Install the battery racks (0.5 day)
    • Task 9: Wire the electricity (1 day)

    Some tasks have to be completed before others – we certainly can’t install the new motor before removing the old engine! There are some tasks, however, that can be worked on simultaneously by two different people, like constructing the battery racks and installing the motor.

    To help us visualize the ordering of tasks, we will create a digraph.

    Digraph

    A diagraph is a graphical representation of a set of tasks in which tasks are represented with dots, called vertices, and arrows between vertices are used to show ordering.

    For example, this digraph shows that Task 1, notated \(T_1\) for compactness, needs to be completed before Task 2. The number in parentheses after the task name is the time required for the task.

    sc1.svg

    Example 1

    A complete digraph for our car conversion would look like this:

    sc2.svg

    The time it takes to complete this job will partially depend upon how many people are working on the project.

    Processors

    In scheduling jargon, the workers completing the tasks are called processors. While in this example the processors are humans, in some situations the processors are computers, robots, or other machines.

    For simplicity, we are going to make the very big assumptions that every processor can do every task, that they all would take the same time to complete it, and that only one processor can work on a task at a time.

    Finishing Time

    The finishing time is how long it will take to complete all the tasks. The finishing time will depend upon the number of processors and the specific schedule.

    If we had only one processor working on this task, it is easy to determine the finishing time; just add up the individual times. We assume one person can’t work on two tasks at the same time, ignore things like drying times during which someone could work on another task. Scheduling with one processor, a possible schedule would look like this, with a finishing time of 10 days.

    clipboard_e38968d98b49af2415b5b701b1ecf6089.png

    In this schedule, all the ordering requirements are met. This is certainly not the only possible schedule for one processor, but no other schedule could complete the job in less time. Because of this, this is an optimal schedule with optimal finishing time – there is nothing better.

    Optimal Schedule

    An optimal schedule is the schedule with the shortest possible finishing time.

    For two processors, things become more interesting. For small digraphs like this, we probably could fiddle around and guess-and-check a pretty good schedule. Here would be a possibility:

    clipboard_e93755d85ea732f6a49a9187f54818ad3.png

    With two processors, the finishing time was reduced to 5.5 days. What was processor 2 doing during the last day? Nothing, because there were no tasks for the processor to do. This is called idle time.

    Idle Time

    Idle time is time in the schedule when there are no tasks available for the processor to work on, so they sit idle.

    Is this schedule optimal? Could it have been completed in 5 days? Because every other task had to be completed before task 9 could start, there would be no way that both processors could be busy during task 9, so it is not possible to create a shorter schedule.

    So how long will it take if we use three processors? About \(10/3 = 3.33\) days? Again we will guess-and-check a schedule:

    clipboard_ee949eace502f3be66e83458757477c80.png

    With three processors, the job still took 4.5 days. It is a little harder to tell whether this schedule is optimal. However, it might be helpful to notice that since Task 1, 2, 6, and 9 have to be completed sequentially, there is no way that this job could be completed in less than \(2+0.5+0.5+1 = 4\) days, regardless of the number of processors. Four days is, for this digraph, the absolute minimum time to complete the job, called the critical time.

    Critical Time

    The critical time is the absolute minimum time to complete the job, regardless of the number of processors working on the tasks.

    Critical time can be determined by looking at the longest sequence of tasks in the digraph, called the critical path 


    This page titled 7.2: Getting Started is shared under a CC BY-SA 3.0 license and was authored, remixed, and/or curated by David Lippman (The OpenTextBookStore) via source content that was edited to the style and standards of the LibreTexts platform; a detailed edit history is available upon request.