Init hw5

files/hw5.txt

@@ -0,0 +1,20 @@
+./hw5/README.md
+
+./hw5/task1/Cargo.lock
+./hw5/task1/Cargo.toml
+./hw5/task1/src/main.rs
+./hw5/task1/src/zombie/mod.rs
+./hw5/task1/src/child/mod.rs
+./hw5/task1/src/child/pstree.rs
+./hw5/task1/src/unit_tests.rs
+./hw5/task1/tests/output.bats
+
+./hw5/simu1/ANSWERS.md
+./hw5/simu1/QUESTIONS.md
+./hw5/simu1/README-scheduler.md
+./hw5/simu1/scheduler.py
+
+./hw5/simu2/ANSWERS.md
+./hw5/simu2/QUESTIONS.md
+./hw5/simu2/README-mlfq.md
+./hw5/simu2/mlfq.py

hw5/README.md

@@ -0,0 +1,30 @@
+# hw5
+
+## Tasks
+
+To fulfill **hw5** you have to solve:
+
+- task1
+- simu1
+- simu2
+
+## Files
+
+You find already or reuse some files for rust tasks. Please remember to use
+cargo to create the relevant projects for each task.
+
+## Pull-Reuest
+
+Please merge any accepted reviews into your branch. If you are ready with the
+homework, all tests run, please create a pull request named **hw5**.
+
+## Credits for hw5
+
+| Task     | max. Credits | Comment |
+| -------- | ------------ | ------- |
+| task1    | 1.5          |         |
+| task2    | 0.5          |         |
+| simu1    | 1            |         |
+| simu2    | 1            |         |
+| Deadline | +1           |         |
+| =        | 5            |         |

hw5/simu1/QUESTIONS.md

@@ -0,0 +1,22 @@
+# Questions 7-Scheduler-Intro
+
+This program, **scheduler.py**, allows you to see how different schedulers
+perform under scheduling metrics such as response time, turnaround time, and
+total wait time. See the README for details.
+
+## Questions
+
+1. Compute the average response time and average turnaround time when running
+   three jobs of length 200 with the SJF and FIFO schedulers.
+1. Now do the same but with jobs of different lengths: 300, 200, and 100.
+1. Now do the same (1.+2.), but also with the RR scheduler and a time-slice of
+   1.
+1. For what types of workloads does SJF deliver the same turnaround times as
+   FIFO?
+1. For what types of workloads and quantum lengths does SJF deliver the same
+   response times as RR?
+1. What happens to response time with SJF as job lengths increase? Can you use
+   the simulator to demonstrate the trend?
+1. What happens to response time with RR as quantum lengths increase? Can you
+   write an equation that gives the average worst-case response time, given N
+   jobs?

hw5/simu1/README-scheduler.md

@@ -0,0 +1,129 @@
+# README Scheduler
+
+This program, **scheduler.py**, allows you to see how different schedulers
+perform under scheduling metrics such as response time, turnaround time, and
+total wait time. Three schedulers are "implemented": FIFO, SJF, and RR.
+
+There are two steps to running the program.
+
+First, run without the -c flag: this shows you what problem to solve without
+revealing the answers. For example, if you want to compute response, turnaround,
+and wait for three jobs using the FIFO policy, run this:
+
+```text
+  ./scheduler.py -p FIFO -j 3 -s 100
+```
+
+If that doesn't work, try this:
+
+```text
+  python ./scheduler.py -p FIFO -j 3 -s 100
+```
+
+This specifies the FIFO policy with three jobs, and, importantly, a specific
+random seed of 100. If you want to see the solution for this exact problem, you
+have to specify this exact same random seed again. Let's run it and see what
+happens. This is what you should see:
+
+```text
+prompt> ./scheduler.py -p FIFO -j 3 -s 100
+ARG policy FIFO
+ARG jobs 3
+ARG maxlen 10
+ARG seed 100
+
+Here is the job list, with the run time of each job:
+  Job 0 (length = 1)
+  Job 1 (length = 4)
+  Job 2 (length = 7)
+
+Compute the turnaround time, response time, and wait time for each job.  When
+you are done, run this program again, with the same arguments, but with -c,
+which will thus provide you with the answers. You can use -s <somenumber> or
+your own job list (-l 10,15,20 for example) to generate different problems for
+yourself.
+```
+
+As you can see from this example, three jobs are generated: job 0 of length 1,
+job 1 of length 4, and job 2 of length 7. As the program states, you can now use
+this to compute some statistics and see if you have a grip on the basic
+concepts.
+
+Once you are done, you can use the same program to "solve" the problem and see
+if you did your work correctly. To do so, use the "-c" flag. The output:
+
+```text
+prompt> ./scheduler.py -p FIFO -j 3 -s 100 -c
+ARG policy FIFO
+ARG jobs 3
+ARG maxlen 10
+ARG seed 100
+
+Here is the job list, with the run time of each job:
+  Job 0 (length = 1)
+  Job 1 (length = 4)
+  Job 2 (length = 7)
+
+** Solutions **
+
+Execution trace:
+  [time   0] Run job 0 for 1.00 secs (DONE)
+  [time   1] Run job 1 for 4.00 secs (DONE)
+  [time   5] Run job 2 for 7.00 secs (DONE)
+
+Final statistics:
+  Job   0 -- Response: 0.00  Turnaround 1.00  Wait 0.00
+  Job   1 -- Response: 1.00  Turnaround 5.00  Wait 1.00
+  Job   2 -- Response: 5.00  Turnaround 12.00  Wait 5.00
+
+  Average -- Response: 2.00  Turnaround 6.00  Wait 2.00
+```
+
+As you can see from the figure, the -c flag shows you what happened. Job 0 ran
+first for 1 second, Job 1 ran second for 4, and then Job 2 ran for 7 seconds.
+Not too hard; it is FIFO, after all! The execution trace shows these results.
+
+The final statistics are useful too: they compute the "response time" (the time
+a job spends waiting after arrival before first running), the "turnaround time"
+(the time it took to complete the job since first arrival), and the total "wait
+time" (any time spent ready but not running). The stats are shown per job and
+then as an average across all jobs. Of course, you should have computed these
+things all before running with the "-c" flag!
+
+If you want to try the same type of problem but with different inputs, try
+changing the number of jobs or the random seed or both. Different random seeds
+basically give you a way to generate an infinite number of different problems
+for yourself, and the "-c" flag lets you check your own work. Keep doing this
+until you feel like you really understand the concepts.
+
+One other useful flag is "-l" (that's a lower-case L), which lets you specify
+the exact jobs you wish to see scheduled. For example, if you want to find out
+how SJF would perform with three jobs of lengths 5, 10, and 15, you can run:
+
+```text
+prompt> ./scheduler.py -p SJF -l 5,10,15
+ARG policy SJF
+ARG jlist 5,10,15
+
+Here is the job list, with the run time of each job:
+  Job 0 (length = 5.0)
+  Job 1 (length = 10.0)
+  Job 2 (length = 15.0)
+...
+```
+
+And then you can use -c to solve it again. Note that when you specify the exact
+jobs, there is no need to specify a random seed or the number of jobs: the jobs
+lengths are taken from your comma-separated list.
+
+Of course, more interesting things happen when you use SJF (shortest-job first)
+or even RR (round robin) schedulers. Try them and see!
+
+And you can always run
+
+```text
+  ./scheduler.py -h
+```
+
+to get a complete list of flags and options (including options such as setting
+the time quantum for the RR scheduler).

hw5/simu1/scheduler.py

@@ -0,0 +1,155 @@
+#! /usr/bin/env python
+
+import sys
+from optparse import OptionParser
+import random
+
+parser = OptionParser()
+parser.add_option("-s", "--seed", default=0, help="the random seed", 
+                  action="store", type="int", dest="seed")
+parser.add_option("-j", "--jobs", default=3, help="number of jobs in the system",
+                  action="store", type="int", dest="jobs")
+parser.add_option("-l", "--jlist", default="", help="instead of random jobs, provide a comma-separated list of run times",
+                  action="store", type="string", dest="jlist")
+parser.add_option("-m", "--maxlen", default=10, help="max length of job",
+                  action="store", type="int", dest="maxlen")
+parser.add_option("-p", "--policy", default="FIFO", help="sched policy to use: SJF, FIFO, RR",
+                  action="store", type="string", dest="policy")
+parser.add_option("-q", "--quantum", help="length of time slice for RR policy", default=1, 
+                  action="store", type="int", dest="quantum")
+parser.add_option("-c", help="compute answers for me", action="store_true", default=False, dest="solve")
+
+(options, args) = parser.parse_args()
+
+random.seed(options.seed)
+
+print 'ARG policy', options.policy
+if options.jlist == '':
+    print 'ARG jobs', options.jobs
+    print 'ARG maxlen', options.maxlen
+    print 'ARG seed', options.seed
+else:
+    print 'ARG jlist', options.jlist
+
+print ''
+
+print 'Here is the job list, with the run time of each job: '
+
+import operator
+
+joblist = []
+if options.jlist == '':
+    for jobnum in range(0,options.jobs):
+        runtime = int(options.maxlen * random.random()) + 1
+        joblist.append([jobnum, runtime])
+        print '  Job', jobnum, '( length = ' + str(runtime) + ' )'
+else:
+    jobnum = 0
+    for runtime in options.jlist.split(','):
+        joblist.append([jobnum, float(runtime)])
+        jobnum += 1
+    for job in joblist:
+        print '  Job', job[0], '( length = ' + str(job[1]) + ' )'
+print '\n'
+
+if options.solve == True:
+    print '** Solutions **\n'
+    if options.policy == 'SJF':
+        joblist = sorted(joblist, key=operator.itemgetter(1))
+        options.policy = 'FIFO'
+    
+    if options.policy == 'FIFO':
+        thetime = 0
+        print 'Execution trace:'
+        for job in joblist:
+            print '  [ time %3d ] Run job %d for %.2f secs ( DONE at %.2f )' % (thetime, job[0], job[1], thetime + job[1])
+            thetime += job[1]
+
+        print '\nFinal statistics:'
+        t     = 0.0
+        count = 0
+        turnaroundSum = 0.0
+        waitSum       = 0.0
+        responseSum   = 0.0
+        for tmp in joblist:
+            jobnum  = tmp[0]
+            runtime = tmp[1]
+            
+            response   = t
+            turnaround = t + runtime
+            wait       = t
+            print '  Job %3d -- Response: %3.2f  Turnaround %3.2f  Wait %3.2f' % (jobnum, response, turnaround, wait)
+            responseSum   += response
+            turnaroundSum += turnaround
+            waitSum       += wait
+            t += runtime
+            count = count + 1
+        print '\n  Average -- Response: %3.2f  Turnaround %3.2f  Wait %3.2f\n' % (responseSum/count, turnaroundSum/count, waitSum/count)
+                     
+    if options.policy == 'RR':
+        print 'Execution trace:'
+        turnaround = {}
+        response = {}
+        lastran = {}
+        wait = {}
+        quantum  = float(options.quantum)
+        jobcount = len(joblist)
+        for i in range(0,jobcount):
+            lastran[i] = 0.0
+            wait[i] = 0.0
+            turnaround[i] = 0.0
+            response[i] = -1
+
+        runlist = []
+        for e in joblist:
+            runlist.append(e)
+
+        thetime  = 0.0
+        while jobcount > 0:
+            # print '%d jobs remaining' % jobcount
+            job = runlist.pop(0)
+            jobnum  = job[0]
+            runtime = float(job[1])
+            if response[jobnum] == -1:
+                response[jobnum] = thetime
+            currwait = thetime - lastran[jobnum]
+            wait[jobnum] += currwait
+            if runtime > quantum:
+                runtime -= quantum
+                ranfor = quantum
+                print '  [ time %3d ] Run job %3d for %.2f secs' % (thetime, jobnum, ranfor)
+                runlist.append([jobnum, runtime])
+            else:
+                ranfor = runtime;
+                print '  [ time %3d ] Run job %3d for %.2f secs ( DONE at %.2f )' % (thetime, jobnum, ranfor, thetime + ranfor)
+                turnaround[jobnum] = thetime + ranfor
+                jobcount -= 1
+            thetime += ranfor
+            lastran[jobnum] = thetime
+
+        print '\nFinal statistics:'
+        turnaroundSum = 0.0
+        waitSum       = 0.0
+        responseSum   = 0.0
+        for i in range(0,len(joblist)):
+            turnaroundSum += turnaround[i]
+            responseSum += response[i]
+            waitSum += wait[i]
+            print '  Job %3d -- Response: %3.2f  Turnaround %3.2f  Wait %3.2f' % (i, response[i], turnaround[i], wait[i])
+        count = len(joblist)
+        
+        print '\n  Average -- Response: %3.2f  Turnaround %3.2f  Wait %3.2f\n' % (responseSum/count, turnaroundSum/count, waitSum/count)
+
+    if options.policy != 'FIFO' and options.policy != 'SJF' and options.policy != 'RR': 
+        print 'Error: Policy', options.policy, 'is not available.'
+        sys.exit(0)
+else:
+    print 'Compute the turnaround time, response time, and wait time for each job.'
+    print 'When you are done, run this program again, with the same arguments,'
+    print 'but with -c, which will thus provide you with the answers. You can use'
+    print '-s <somenumber> or your own job list (-l 10,15,20 for example)'
+    print 'to generate different problems for yourself.'
+    print ''
+
+
+

hw5/simu2/QUESTIONS.md

@@ -0,0 +1,27 @@
+# Questions: 8-Scheduler-MLFQ
+
+This program, **mlfq.py**, allows you to see how the MLFQ scheduler presented in
+this chapter behaves. See the README for details.
+
+Run a few randomly-generated problems with just two jobs and two queues; compute
+the MLFQ execution trace for each. Make your life easier by limiting the length
+of each job and turning off I/Os.
+
+## Questions
+
+1. How would you run the scheduler to reproduce each of the examples in the
+   chapter? Give to each figure number of the PDF chapter the corresponding
+   simulator call.
+1. How would you configure the scheduler parameters to behave just like a
+   round-robin scheduler?
+1. Craft a workload with two jobs and scheduler parameters so that one job takes
+   advantage of the older Rules 4a and 4b (turned on with the -S flag) to game
+   the scheduler and obtain 99% of the CPU over a particular time interval.
+1. Given a system with a quantum length of 10ms in its highest queue, how often
+   would you have to boost jobs back to the highest priority level (with the -B
+   flag) in order to guarantee that a single long-running (and
+   potentially-starving) job gets at least 5% of the CPU?
+1. One question that arises in scheduling is which end of a queue to add a job
+   that just finished I/O; the -I flag changes this behavior for this scheduling
+   simulator. Play around with some workloads and see if you can see the effect
+   of this flag.

hw5/simu2/README-mlfq.md

@@ -0,0 +1,184 @@
+# README Scheduler: MLFQ
+
+This program, **mlfq.py**, allows you to see how the MLFQ scheduler presented in
+this chapter behaves. As before, you can use this to generate problems for
+yourself using random seeds, or use it to construct a carefully-designed
+experiment to see how MLFQ works under different circumstances. To run the
+program, type:
+
+```text
+prompt> ./mlfq.py
+```
+
+Use the help flag (-h) to see the options:
+
+```text
+Usage: mlfq.py [options]
+Options:
+  -h, --help            show this help message and exit
+  -s SEED, --seed=SEED  the random seed
+  -n NUMQUEUES, --numQueues=NUMQUEUES
+                        number of queues in MLFQ (if not using -Q)
+  -q QUANTUM, --quantum=QUANTUM
+                        length of time slice (if not using -Q)
+  -Q QUANTUMLIST, --quantumList=QUANTUMLIST
+                        length of time slice per queue level,
+                        specified as x,y,z,... where x is the
+                        quantum length for the highest-priority
+                        queue, y the next highest, and so forth
+  -j NUMJOBS, --numJobs=NUMJOBS
+                        number of jobs in the system
+  -m MAXLEN, --maxlen=MAXLEN
+                        max run-time of a job (if random)
+  -M MAXIO, --maxio=MAXIO
+                        max I/O frequency of a job (if random)
+  -B BOOST, --boost=BOOST
+                        how often to boost the priority of all
+                        jobs back to high priority (0 means never)
+  -i IOTIME, --iotime=IOTIME
+                        how long an I/O should last (fixed constant)
+  -S, --stay            reset and stay at same priority level
+                        when issuing I/O
+  -l JLIST, --jlist=JLIST
+                        a comma-separated list of jobs to run,
+                        in the form x1,y1,z1:x2,y2,z2:... where
+                        x is start time, y is run time, and z
+                        is how often the job issues an I/O request
+  -c                    compute answers for me
+```
+
+There are a few different ways to use the simulator. One way is to generate some
+random jobs and see if you can figure out how they will behave given the MLFQ
+scheduler. For example, if you wanted to create a randomly-generated three-job
+workload, you would simply type:
+
+```text
+prompt> ./mlfq.py -j 3
+```
+
+What you would then see is the specific problem definition:
+
+```text
+Here is the list of inputs:
+OPTIONS jobs 3
+OPTIONS queues 3
+OPTIONS quantum length for queue  2 is  10
+OPTIONS quantum length for queue  1 is  10
+OPTIONS quantum length for queue  0 is  10
+OPTIONS boost 0
+OPTIONS ioTime 0
+OPTIONS stayAfterIO False
+
+
+For each job, three defining characteristics are given:
+  startTime : at what time does the job enter the system
+  runTime   : the total CPU time needed by the job to finish
+  ioFreq    : every ioFreq time units, the job issues an I/O
+              (the I/O takes ioTime units to complete)
+
+Job List:
+  Job  0: startTime   0 - runTime  84 - ioFreq   7
+  Job  1: startTime   0 - runTime  42 - ioFreq   2
+  Job  2: startTime   0 - runTime  51 - ioFreq   4
+
+Compute the execution trace for the given workloads.
+If you would like, also compute the response and turnaround
+times for each of the jobs.
+
+Use the -c flag to get the exact results when you are finished.
+```
+
+This generates a random workload of three jobs (as specified), on the default
+number of queues with a number of default settings. If you run again with the
+solve flag on (-c), you'll see the same print out as above, plus the following:
+
+```text
+Execution Trace:
+
+[time 0] JOB BEGINS by JOB 0
+[time 0] JOB BEGINS by JOB 1
+[time 0] JOB BEGINS by JOB 2
+[time 0] Run JOB 0 at PRI 2 [TICKSLEFT 9 RUNTIME 84 TIMELEFT 83]
+[time 1] Run JOB 0 at PRI 2 [TICKSLEFT 8 RUNTIME 84 TIMELEFT 82]
+[time 2] Run JOB 0 at PRI 2 [TICKSLEFT 7 RUNTIME 84 TIMELEFT 81]
+[time 3] Run JOB 0 at PRI 2 [TICKSLEFT 6 RUNTIME 84 TIMELEFT 80]
+[time 4] Run JOB 0 at PRI 2 [TICKSLEFT 5 RUNTIME 84 TIMELEFT 79]
+[time 5] Run JOB 0 at PRI 2 [TICKSLEFT 4 RUNTIME 84 TIMELEFT 78]
+[time 6] Run JOB 0 at PRI 2 [TICKSLEFT 3 RUNTIME 84 TIMELEFT 77]
+[time 7] IO_START by JOB 0
+[time 7] Run JOB 1 at PRI 2 [TICKSLEFT 9 RUNTIME 42 TIMELEFT 41]
+[time 8] Run JOB 1 at PRI 2 [TICKSLEFT 8 RUNTIME 42 TIMELEFT 40]
+[time 9] IO_START by JOB 1
+
+...
+
+Final statistics:
+  Job  0: startTime   0 - response   0 - turnaround 175
+  Job  1: startTime   0 - response   7 - turnaround 191
+  Job  2: startTime   0 - response   9 - turnaround 168
+
+  Avg  2: startTime n/a - response 5.33 - turnaround 178.00
+```
+
+The trace shows exactly, on a millisecond-by-millisecond time scale, what the
+scheduler decided to do. In this example, it begins by running Job 0 for 7 ms
+until Job 0 issues an I/O; this is entirely predictable, as Job 0's I/O
+frequency is set to 7 ms, meaning that every 7 ms it runs, it will issue an I/O
+and wait for it to complete before continuing. At that point, the scheduler
+switches to Job 1, which only runs 2 ms before issuing an I/O. The scheduler
+prints the entire execution trace in this manner, and finally also computes the
+response and turnaround times for each job as well as an average.
+
+You can also control various other aspects of the simulation. For example, you
+can specify how many queues you'd like to have in the system (-n) and what the
+quantum length should be for all of those queues (-q); if you want even more
+control and varied quanta length per queue, you can instead specify the length
+of the quantum for each queue with -Q, e.g., -Q 10,20,30] simulates a scheduler
+with three queues, with the highest-priority queue having a 10-ms time slice,
+the next-highest a 20-ms time-slice, and the low-priority queue a 30-ms time
+slice.
+
+If you are randomly generating jobs, you can also control how long they might
+run for (-m), or how often they generate I/O (-M). If you, however, want more
+control over the exact characteristics of the jobs running in the system, you
+can use -l (lower-case L) or --jlist, which allows you to specify the exact set
+of jobs you wish to simulate. The list is of the form: x1,y1,z1:x2,y2,z2:...
+where x is the start time of the job, y is the run time (i.e., how much CPU time
+it needs), and z the I/O frequency (i.e., after running z ms, the job issues an
+I/O; if z is 0, no I/Os are issued).
+
+For example, if you wanted to recreate the example in Figure 8.3 you would
+specify a job list as follows:
+
+```text
+prompt> ./mlfq.py --jlist 0,180,0:100,20,0 -Q 10,10,10
+```
+
+Running the simulator in this way creates a three-level MLFQ, with each level
+having a 10-ms time slice. Two jobs are created: Job 0 which starts at time 0,
+runs for 180 ms total, and never issues an I/O; Job 1 starts at 100 ms, needs
+only 20 ms of CPU time to complete, and also never issues I/Os.
+
+Finally, there are three more parameters of interest. The -B flag, if set to a
+non-zero value, boosts all jobs to the highest-priority queue every N
+milliseconds, when invoked as such:
+
+```text
+  prompt> ./mlfq.py -B N
+```
+
+The scheduler uses this feature to avoid starvation as discussed in the chapter.
+However, it is off by default.
+
+The -S flag invokes older Rules 4a and 4b, which means that if a job issues an
+I/O before completing its time slice, it will return to that same priority queue
+when it resumes execution, with its full time-slice intact.  This enables gaming
+of the scheduler.
+
+Finally, you can easily change how long an I/O lasts by using the -i flag. By
+default in this simplistic model, each I/O takes a fixed amount of time of 5
+milliseconds or whatever you set it to with this flag.
+
+You can also play around with whether jobs that just complete an I/O are moved
+to the head of the queue they are in or to the back, with the -I flag. Check it
+out.

hw5/simu2/mlfq.py

@@ -0,0 +1,338 @@
+#! /usr/bin/env python
+
+import sys
+from optparse import OptionParser
+import random
+
+# finds the highest nonempty queue
+# -1 if they are all empty
+def FindQueue():
+    q = hiQueue
+    while q > 0:
+        if len(queue[q]) > 0:
+            return q
+        q -= 1
+    if len(queue[0]) > 0:
+        return 0
+    return -1
+
+def LowerQueue(currJob, currQueue, issuedIO):
+    if currQueue > 0:
+        # in this case, have to change the priority of the job
+        job[currJob]['currPri'] = currQueue - 1
+        if issuedIO == False:
+            queue[currQueue-1].append(currJob)
+        job[currJob]['ticksLeft'] = quantum[currQueue-1]
+    else:
+        if issuedIO == False:
+            queue[currQueue].append(currJob)
+        job[currJob]['ticksLeft'] = quantum[currQueue]
+
+def Abort(str):
+    sys.stderr.write(str + '\n')
+    exit(1)
+
+
+#
+# PARSE ARGUMENTS
+#
+
+parser = OptionParser()
+parser.add_option('-s', '--seed', help='the random seed', 
+                  default=0, action='store', type='int', dest='seed')
+parser.add_option('-n', '--numQueues',
+                  help='number of queues in MLFQ (if not using -Q)', 
+                  default=3, action='store', type='int', dest='numQueues')
+parser.add_option('-q', '--quantum', help='length of time slice (if not using -Q)',
+                  default=10, action='store', type='int', dest='quantum')
+parser.add_option('-Q', '--quantumList',
+                  help='length of time slice per queue level, specified as ' + \
+                  'x,y,z,... where x is the quantum length for the highest ' + \
+                  'priority queue, y the next highest, and so forth', 
+                  default='', action='store', type='string', dest='quantumList')
+parser.add_option('-j', '--numJobs', default=3, help='number of jobs in the system',
+                  action='store', type='int', dest='numJobs')
+parser.add_option('-m', '--maxlen', default=100, help='max run-time of a job ' +
+                  '(if randomly generating)', action='store', type='int',
+                  dest='maxlen')
+parser.add_option('-M', '--maxio', default=10,
+                  help='max I/O frequency of a job (if randomly generating)',
+                  action='store', type='int', dest='maxio')
+parser.add_option('-B', '--boost', default=0,
+                  help='how often to boost the priority of all jobs back to ' +
+                  'high priority', action='store', type='int', dest='boost')
+parser.add_option('-i', '--iotime', default=5,
+                  help='how long an I/O should last (fixed constant)',
+                  action='store', type='int', dest='ioTime')
+parser.add_option('-S', '--stay', default=False,
+                  help='reset and stay at same priority level when issuing I/O',
+                  action='store_true', dest='stay')
+parser.add_option('-I', '--iobump', default=False,
+                  help='if specified, jobs that finished I/O move immediately ' + \
+                  'to front of current queue',
+                  action='store_true', dest='iobump')
+parser.add_option('-l', '--jlist', default='',
+                  help='a comma-separated list of jobs to run, in the form ' + \
+                  'x1,y1,z1:x2,y2,z2:... where x is start time, y is run ' + \
+                  'time, and z is how often the job issues an I/O request',
+                  action='store', type='string', dest='jlist')
+parser.add_option('-c', help='compute answers for me', action='store_true',
+                  default=False, dest='solve')
+
+(options, args) = parser.parse_args()
+
+random.seed(options.seed)
+
+
+# MLFQ: How Many Queues
+numQueues = options.numQueues
+
+quantum = {}
+if options.quantumList != '':
+    # instead, extract number of queues and their time slic
+    quantumLengths = options.quantumList.split(',')
+    numQueues = len(quantumLengths)
+    qc = numQueues - 1
+    for i in range(numQueues):
+        quantum[qc] = int(quantumLengths[i])
+        qc -= 1
+else:
+    for i in range(numQueues):
+        quantum[i] = int(options.quantum)
+
+hiQueue = numQueues - 1
+
+# MLFQ: I/O Model
+# the time for each IO: not great to have a single fixed time but...
+ioTime = int(options.ioTime)
+
+# This tracks when IOs and other interrupts are complete
+ioDone = {}
+
+# This stores all info about the jobs
+job = {}
+
+# seed the random generator
+random.seed(options.seed)
+
+# jlist 'startTime,runTime,ioFreq:startTime,runTime,ioFreq:...'
+jobCnt = 0
+if options.jlist != '':
+    allJobs = options.jlist.split(':')
+    for j in allJobs:
+        jobInfo = j.split(',')
+        if len(jobInfo) != 3:
+            sys.stderr.write('Badly formatted job string. Should be x1,y1,z1:x2,y2,z2:...\n')
+            sys.stderr.write('where x is the startTime, y is the runTime, and z is the I/O frequency.\n')
+            exit(1)
+        assert(len(jobInfo) == 3)
+        startTime = int(jobInfo[0])
+        runTime   = int(jobInfo[1])
+        ioFreq    = int(jobInfo[2])
+        job[jobCnt] = {'currPri':hiQueue, 'ticksLeft':quantum[hiQueue], 'startTime':startTime,
+                       'runTime':runTime, 'timeLeft':runTime, 'ioFreq':ioFreq, 'doingIO':False,
+                       'firstRun':-1}
+        if startTime not in ioDone:
+            ioDone[startTime] = []
+        ioDone[startTime].append((jobCnt, 'JOB BEGINS'))
+        jobCnt += 1
+else:
+    # do something random
+    for j in range(options.numJobs):
+        startTime = 0
+        # runTime   = int(random.random() * options.maxlen)
+        # ioFreq    = int(random.random() * options.maxio)
+        runTime   = int(random.random() * (options.maxlen - 1) + 1)
+        ioFreq    = int(random.random() * (options.maxio - 1) + 1)
+        
+        job[jobCnt] = {'currPri':hiQueue, 'ticksLeft':quantum[hiQueue], 'startTime':startTime,
+                       'runTime':runTime, 'timeLeft':runTime, 'ioFreq':ioFreq, 'doingIO':False,
+                       'firstRun':-1}
+        if startTime not in ioDone:
+            ioDone[startTime] = []
+        ioDone[startTime].append((jobCnt, 'JOB BEGINS'))
+        jobCnt += 1
+
+
+numJobs = len(job)
+
+print 'Here is the list of inputs:'
+print 'OPTIONS jobs',            numJobs
+print 'OPTIONS queues',          numQueues
+for i in range(len(quantum)-1,-1,-1):
+    print 'OPTIONS quantum length for queue %2d is %3d' % (i, quantum[i])
+print 'OPTIONS boost',           options.boost
+print 'OPTIONS ioTime',          options.ioTime
+print 'OPTIONS stayAfterIO',     options.stay
+print 'OPTIONS iobump',          options.iobump
+
+print '\n'
+print 'For each job, three defining characteristics are given:'
+print '  startTime : at what time does the job enter the system'
+print '  runTime   : the total CPU time needed by the job to finish'
+print '  ioFreq    : every ioFreq time units, the job issues an I/O'
+print '              (the I/O takes ioTime units to complete)\n'
+
+print 'Job List:'
+for i in range(numJobs):
+    print '  Job %2d: startTime %3d - runTime %3d - ioFreq %3d' % (i, job[i]['startTime'],
+                                                                   job[i]['runTime'], job[i]['ioFreq'])
+print ''
+
+if options.solve == False:
+    print 'Compute the execution trace for the given workloads.'
+    print 'If you would like, also compute the response and turnaround'
+    print 'times for each of the jobs.'
+    print ''
+    print 'Use the -c flag to get the exact results when you are finished.\n'
+    exit(0)
+
+# initialize the MLFQ queues
+queue = {}
+for q in range(numQueues):
+    queue[q] = []
+
+# TIME IS CENTRAL
+currTime = 0
+
+# use these to know when we're finished
+totalJobs    = len(job)
+finishedJobs = 0
+
+print '\nExecution Trace:\n'
+
+while finishedJobs < totalJobs:
+    # find highest priority job
+    # run it until either
+    # (a) the job uses up its time quantum
+    # (b) the job performs an I/O
+
+    # check for priority boost
+    if options.boost > 0 and currTime != 0:
+        if currTime % options.boost == 0:
+            print '[ time %d ] BOOST ( every %d )' % (currTime, options.boost)
+            # remove all jobs from queues (except high queue)
+            for q in range(numQueues-1):
+                for j in queue[q]:
+                    if job[j]['doingIO'] == False:
+                        queue[hiQueue].append(j)
+                queue[q] = []
+            # print 'BOOST: QUEUES look like:', queue
+
+            # change priority to high priority
+            # reset number of ticks left for all jobs (XXX just for lower jobs?)
+            # add to highest run queue (if not doing I/O)
+            for j in range(numJobs):
+                # print '-> Boost %d (timeLeft %d)' % (j, job[j]['timeLeft'])
+                if job[j]['timeLeft'] > 0:
+                    # print '-> FinalBoost %d (timeLeft %d)' % (j, job[j]['timeLeft'])
+                    job[j]['currPri']   = hiQueue
+                    job[j]['ticksLeft'] = quantum[hiQueue]
+            # print 'BOOST END: QUEUES look like:', queue
+
+    # check for any I/Os done
+    if currTime in ioDone:
+        for (j, type) in ioDone[currTime]:
+            q = job[j]['currPri']
+            job[j]['doingIO'] = False
+            print '[ time %d ] %s by JOB %d' % (currTime, type, j)
+            if options.iobump == False or type == 'JOB BEGINS':
+                queue[q].append(j)
+            else:
+                queue[q].insert(0, j)
+
+    # now find the highest priority job
+    currQueue = FindQueue()
+    if currQueue == -1:
+        print '[ time %d ] IDLE' % (currTime)
+        currTime += 1
+        continue
+    #print 'FOUND QUEUE: %d' % currQueue
+    #print 'ALL QUEUES:', queue
+            
+    # there was at least one runnable job, and hence ...
+    currJob = queue[currQueue][0]
+    if job[currJob]['currPri'] != currQueue:
+        Abort('currPri[%d] does not match currQueue[%d]' % (job[currJob]['currPri'], currQueue))
+
+    job[currJob]['timeLeft']  -= 1
+    job[currJob]['ticksLeft'] -= 1
+
+    if job[currJob]['firstRun'] == -1:
+        job[currJob]['firstRun'] = currTime
+
+    runTime   = job[currJob]['runTime']
+    ioFreq    = job[currJob]['ioFreq']
+    ticksLeft = job[currJob]['ticksLeft']
+    timeLeft  = job[currJob]['timeLeft']
+
+    print '[ time %d ] Run JOB %d at PRIORITY %d [ TICKSLEFT %d RUNTIME %d TIMELEFT %d ]' % \
+          (currTime, currJob, currQueue, ticksLeft, runTime, timeLeft)
+
+    if timeLeft < 0:
+        Abort('Error: should never have less than 0 time left to run')
+
+
+    # UPDATE TIME
+    currTime += 1
+
+    # CHECK FOR JOB ENDING
+    if timeLeft == 0:
+        print '[ time %d ] FINISHED JOB %d' % (currTime, currJob)
+        finishedJobs += 1
+        job[currJob]['endTime'] = currTime
+        # print 'BEFORE POP', queue
+        done = queue[currQueue].pop(0)
+        # print 'AFTER POP', queue
+        assert(done == currJob)
+        continue
+
+    # CHECK FOR IO
+    issuedIO = False
+    if ioFreq > 0 and (((runTime - timeLeft) % ioFreq) == 0):
+        # time for an IO!
+        print '[ time %d ] IO_START by JOB %d' % (currTime, currJob)
+        issuedIO = True
+        desched = queue[currQueue].pop(0)
+        assert(desched == currJob)
+        job[currJob]['doingIO'] = True
+        # this does the bad rule -- reset your tick counter if you stay at the same level
+        if options.stay == True:
+            job[currJob]['ticksLeft'] = quantum[currQueue]
+        # add to IO Queue: but which queue?
+        futureTime = currTime + ioTime
+        if futureTime not in ioDone:
+            ioDone[futureTime] = []
+        print 'IO DONE'
+        ioDone[futureTime].append((currJob, 'IO_DONE'))
+        # print 'NEW IO EVENT at ', futureTime, ' is ', ioDone[futureTime]
+        
+    # CHECK FOR QUANTUM ENDING AT THIS LEVEL
+    if ticksLeft == 0:
+        # print '--> DESCHEDULE %d' % currJob
+        if issuedIO == False:
+            # print '--> BUT IO HAS NOT BEEN ISSUED (therefor pop from queue)'
+            desched = queue[currQueue].pop(0)
+        assert(desched == currJob)
+        # move down one queue! (unless lowest queue)
+        LowerQueue(currJob, currQueue, issuedIO)
+
+
+# print out statistics
+print ''
+print 'Final statistics:'
+responseSum   = 0
+turnaroundSum = 0
+for i in range(numJobs):
+    response   = job[i]['firstRun'] - job[i]['startTime']
+    turnaround = job[i]['endTime'] - job[i]['startTime']
+    print '  Job %2d: startTime %3d - response %3d - turnaround %3d' % (i, job[i]['startTime'],
+                                                                        response, turnaround)
+    responseSum   += response
+    turnaroundSum += turnaround
+
+print '\n  Avg %2d: startTime n/a - response %.2f - turnaround %.2f' % (i, 
+                                                                        float(responseSum)/numJobs,
+                                                                        float(turnaroundSum)/numJobs)
+
+print '\n'

hw5/task1/README.md

@@ -0,0 +1,243 @@
+# Homework hw5 task1
+
+- [1.1. Ziel](#11-ziel)
+- [1.2. Externe Crate nutzen](#12-externe-crate-nutzen)
+    - [1.2.1. Versionen der externen Crates](#121-versionen-der-externen-crates)
+- [1.3. Aufgaben](#13-aufgaben)
+    - [1.3.1. Optionale Parameter](#131-optionale-parameter)
+    - [1.3.2. Externe Crate in Dependencies eintragen](#132-externe-crate-in-dependencies-eintragen)
+    - [1.3.3. Die Funktion `pub fn run_zombie()`](#133-die-funktion-pub-fn-runzombie)
+    - [1.3.4. Die Funktion `pub fn run_childs(start_pid: i32, arg: &str) -> Result<(), String>`](#134-die-funktion-pub-fn-runchildsstartpid-i32-arg-str---result-string)
+- [1.4. Tests](#14-tests)
+- [1.5. Dokumentation](#15-dokumentation)
+- [1.6. Kontrolle Ihres Repositories](#16-kontrolle-ihres-repositories)
+
+## 1.1. Ziel
+
+Ziel dieser Aufgabe ist es, mittels des externen Crates *nix* einige systemnahe
+Funktionen zur Prozesserzeugung und -synchronisierung kennen zu lernen.
+
+Über optionale Aufrufparameter werden die verschiedenen Verhaltensweisen Ihres
+Programms getrickert.
+
+## 1.2. Externe Crate nutzen
+
+Um möglichst direkt die Systemfunktionen zu nutzen, stellt das *[nix Crate][]*
+eine einheitliche Schnittstelle dar. Insbesondere der Umgang mit der
+Fehlerbehandlung ist unter Rust und der nix Crate um einiges komfortabler und
+sicherer. Dazu stellt die nix Crate über den Result Typ die Informationen über
+den aufgerufenen Systemcall zur Verfügung. Rust Datentypen werden in der nix
+Crate überall dort benutzt wo dies Sinn macht. So werden z.B. Slices als
+Standard benutzt, wenn Bereiche eines Puffers weitergegeben werden müssen.
+Dieser Standard soll nun wiederum in C++ im C++17 Standard einfließen.
+
+In dieser Aufgabe interessieren wir uns vor allem für das *nix* Modul
+`nix::unistd` und `nix::sys::wait`. Darüber hinaus werden auch weitere Rust
+Standard-Library Methoden benutzt, sowie die externe Crate *procinfo*
+eingebunden.
+
+### 1.2.1. Versionen der externen Crates
+
+- *nix*: 0.9.0
+- *procinfo*: 0.4.2
+
+In Ihrer Lösung dürfen nur diese beiden externen Crates eingebunden werden.
+
+## 1.3. Aufgaben
+
+### 1.3.1. Optionale Parameter
+
+Ihr Programm wird sich entsprechend der übergebenen Optionen unterschiedlich
+verhalten:
+
+- ohne Parameter: Aufruf der Funktion `pub fn run_zombie()`
+- ein Parameter: Aufruf der Funktion `pub fn run_childs(start_pid: i32, arg:
+  &str) -> Result<(), String>`
+
+Details zu den einzelnen Funktionen erhalten Sie bei den entsprechenden Aufgaben
+dazu.
+
+### 1.3.2. Externe Crate in Dependencies eintragen
+
+- Benutzen Sie für die folgenden Aufgaben das *[nix Crate][]*.
+- Fügen Sie dazu den notwendigen Eintrag unter `[dependencies]` in
+  **Cargo.toml** hinzu und benutzen in Ihrem Root Modul `main.rs` die
+  entsprechende extern Anweisung.
+
+### 1.3.3. Die Funktion `pub fn run_zombie()`
+
+Wird das Programm ohne einen Parameter aufgerufen, erstellen wir als 'Belohnung'
+für diesen 'müden' Programmaufruf einen Zombie! Dies geschieht im Modul
+*zombie/mod.rs* über die dortige Funktion `pub fn run_zombie()`. Innerhalb
+dieser Funktion behandeln Sie evtl. auftretende Fehler direkt mit
+Programmabbruch. Dies gilt jedoch nur für diesen Aufgabenpunkt!
+
+Was ist ein Zombieprozess?
+
+>"Wenn ein Prozess einen neuen Prozess startet (mittels Forking), wird der alte
+>'Elternprozess' und der neue 'Kindprozess' genannt. Wenn der Kindprozess
+>beendet wird, kann der Elternprozess vom Betriebssystem erfragen, auf welche
+>Art der Kindprozess beendet wurde: erfolgreich, mit Fehler, abgestürzt,
+>abgebrochen, etc.
+>
+>Um diese Abfrage zu ermöglichen, bleibt ein Prozess, selbst nachdem er beendet
+>wurde, in der Prozesstabelle stehen, bis der Elternprozess diese Abfrage
+>durchführt – egal ob diese Information gebraucht wird oder nicht. Bis dahin hat
+>der Kindprozess den Zustand Zombie. In diesem Zustand belegt der Prozess selbst
+>keinen Arbeitsspeicher mehr (bis auf den platzmäßig vernachlässigbaren Eintrag
+>in der Prozesstabelle des Kernels) und verbraucht auch keine Rechenzeit, jedoch
+>behält er seine PID, die (noch) nicht für andere Prozesse wiederverwendet
+>werden kann." ([Quelle Wikipedia][])
+
+Die Funktion `run_zombie()` erstellen Sie im Modul *zombie/mod.rs*. Wenn Sie Ihr
+Programm ohne Parameter aufrufen, erhalten Sie bei korrekter Zombie
+'Generierung' folgende Ausgabe:
+
+```text
+PID   TTY      STAT   TIME COMMAND
+27524 pts/1    Ss     0:00 -bash
+27531 pts/1    S      0:00 zsh
+27935 pts/1    S+     0:00 cargo run
+27936 pts/1    S+     0:00 target/debug/task1
+27962 pts/1    Z+     0:00 [task1] \<defunct\>
+27963 pts/1    R+     0:00 ps t
+```
+
+Diese Ausgabe wird über das Programm **ps t** generiert, welches in Ihrem
+Programm dann geschickterweise aufgerufen wird, wenn Sie den im vorherigen Text
+beschriebenen Zustand durch Ihr Programm selbst hergestellt haben. Den
+Zombizustand bekommen Sie als Z dargestellt, siehe auch [man ps][].
+
+>Tipp: Um Ihr Programm einen Moment 'schlafen' zu lassen, stellt Ihnen Rust die
+>Funktion [thread::sleep][] zur Verfügung. Ein Prozess besteht aus mindestens
+>einem Thread (Main-Thread). Und da Sie keine weiteren Threads erstellen, lässt
+>diese Funktion Ihren Prozess (bestehend aus einem Main-Thread) schlafen.
+
+Um ein anderes Programm aus Ihrem Programm heraus starten zu lassen stellen
+Ihnen die *nix* Crate und die `std Bibliothek verschiedene Funktionen` bereit:
+
+- [Module nix::unistd][] der *nix* Crate: die Funktion execv(), execve() und
+   execvp()
+
+- [Module std::process][] der Standardbibliothek: Machen Sie sich mit der
+   Benutzung von [Module std::process][] grob vertraut, insbesondere die
+   Methoden des Typs [Command][]:
+
+  - new
+  - arg
+  - spawn
+  - output
+  - status
+
+Je nachdem für welche Bibliothek Sie sich entscheiden, experimentieren Sie zu
+Beginn ein wenig mit den Code Beispielen der Dokumentation.
+
+>Tipp: Das Command Interface der Standardbibliothek ist einfacher zu verwenden.
+
+### 1.3.4. Die Funktion `pub fn run_childs(start_pid: i32, arg: &str) -> Result<(), String>`
+
+Wird ein Parameter (`arg`) beim Aufruf Ihres Programms mit angegeben,
+spezifiziert dieser Parameter die Anzahl der zu erzeugenden Kindprozesse.
+Wichtig dabei ist, dass alle zu erstellenden Kindprozesse voneinander abhängen.
+Rufen Sie im letzten erstellten Kindprozess Ihre bereits erstellte `pstree()`
+Funktion mit der übergebenen PID des 1. Elternprozesses (`start_pid`) auf, so
+können Sie aufgrund der ausgegebenen Liste erkennen, ob alle Kindprozess
+voneinander abhängen. Ihr *pstree* Modul stellen Sie in *child/pstree.rs*
+bereit, da dieses nur im Modul *child/mod.rs* benutzt werden muss.
+
+> Die Pid aus dem **nix Crate** ist vom Typ `Pid`, welches ein Alias ist. Lesen
+> Sie dazu die Dokumentation des nix Crates und benutzen Sie eine geeignete Rust
+> Funktion (einer Trait), um diesen Typ als i32 an Ihre Funktion `run_childs()`
+> weiterzugeben. Sie müssen in der **pstree Funktion** dazu nichts anpassen!
+
+```text
+> ./target/debug/task1 4
+...
+task1(28207)---task1(28233)---task1(28234)---task1(28235)---task1(28236)
+...
+```
+
+Implementieren Sie die Funktion `pub fn run_childs(start_pid: i32, arg: &str) ->
+Result<(), String>` im Modul *child/mod.rs*. Alle dazu nötigen Hilfsfunktionen
+werden entweder in *child/mod.rs* oder entsprechenden Modulen im *child/*
+Verzeichnis zur Verfügung gestellt. Evtl. auftretende Fehler werden an das Root
+Modul (*main.rs*) zurückgegeben und dort behandelt. Bei dieser Teilaufgabe
+müssen alle auftretenden Fehler entsprechend an das Root-Modul zurückgegeben
+werden. Treten Fehler auf, so darf die Fehlermeldung, generiert im Root-Modul,
+dazu max. 1 Zeile lang sein und der Exit-Code des Programms muss '1' sein.
+
+Parsen Sie den übergebenen Parameter mit der `parse()` Funktion in einen `u8`
+Typ! Es ist wichtig, dass Sie im weiteren die Anzahl der Kindprozesse über eine
+`u8` Variable steuern!
+
+Jedes Child soll eine Ausgabe machen, sowie jeder Parent, wenn sich der Child
+beendet hat:
+
+- Child: hello, I am child (\<pid\>)
+- Eltern: I am \<pid\> and my child is \<child\>.  After I waited for
+  \<waitstatuspid\>, it sent me status \<status\>
+
+  - \<pid\> via getpid()
+  - \<child\> = child pid
+  - \<waitstatuspid\> = see Ok of waitpid()
+  - \<status\> = see Ok of waitpid()
+
+```text
+> ./target/debug/task1 4
+hello, I am child (pid:28233)
+hello, I am child (pid:28234)
+hello, I am child (pid:28235)
+hello, I am child (pid:28236)
+
+task1(28207)---task1(28233)---task1(28234)---task1(28235)---task1(28236)
+I am 28235 and my child is 28236.  After I waited for 28236, it sent me status 0
+I am 28234 and my child is 28235.  After I waited for 28235, it sent me status 0
+I am 28233 and my child is 28234.  After I waited for 28234, it sent me status 0
+I am 28207 and my child is 28233.  After I waited for 28233, it sent me status 0
+```
+
+>Leerzeile wichtig nach der Ausgabe aller Kinder!
+
+## 1.4. Tests
+
+Für das *tests/* Verzeichnis steht wieder eine *output.bats* Datei zur
+Verfügung. Ausserdem erstellen Sie bitte eigene Unit Tests in einer eigenen zu
+erstellenden *unit_tests.rs* Datei in Ihrem Crate Root Verzeichnis (*src/*).
+
+## 1.5. Dokumentation
+
+Erstellen Sie für alle Module und Funktionen eine kurze aber aussagekräftige
+Dokumentation, und vergessen Sie nicht wichtige Passagen auch im Code zu
+kommentieren. Als Tutoren sollte es uns möglich sein, schnell Ihre genialen
+Lösungen nachvollziehen zu können.
+
+## 1.6. Kontrolle Ihres Repositories
+
+Haben Sie die Aufgaben komplett bearbeitet, so sollten sich folgende Dateien in
+Ihrem HW (Homework) Verzeichnis befinden:
+
+```text
+.
+├── Cargo.lock
+├── Cargo.toml
+├── README.md
+├── src
+│   ├── child
+│   │   ├── mod.rs
+│   │   └── pstree.rs
+│   ├── main.rs
+│   └── zombie
+│       └── mod.rs
+└── tests
+    └── output.bats
+
+4 directories, 8 files
+```
+
+[nix Crate]: https://docs.rs/nix/0.8.1/nix/
+[Module nix::unistd]: https://docs.rs/nix/0.8.1/nix/unistd/index.html
+[Module std::process]: https://doc.rust-lang.org/std/process/
+[Command]: https://doc.rust-lang.org/std/process/struct.Command.html
+[Quelle Wikipedia]: https://de.wikipedia.org/wiki/Zombie-Prozess
+[thread::sleep]: https://doc.rust-lang.org/std/thread/fn.sleep.html
+[man ps]: http://man7.org/linux/man-pages/man1/ps.1.html

hw5/task1/tests/output.bats

@@ -0,0 +1,104 @@
+#!/usr/bin/env bats
+
+
+@test "task1: Check that we have a debug output" {
+    run stat "$BATS_TEST_DIRNAME/../target/debug/task1"
+    [ "$status" -eq 0 ]
+}
+
+# Check lines of output
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with Zombie must at least 4 Lines long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' | wc -l | xargs"
+    [ "$output" -gt 4 ]
+
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with to many paras must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 2 3 4 | wc -l | xargs"
+    [ "$output" = "1" ]
+
+}
+
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with wrong para must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' y | wc -l | xargs"
+    [ "$output" = "1" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with wrong para must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' -1 | wc -l | xargs"
+    [ "$output" = "1" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with para 0 must be exact 0 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 0 | wc -l | xargs"
+    [ "$output" = "0" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with para 256 must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 256 | wc -l | xargs"
+    [ "$output" = "1" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with para 1 must be exact 4 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 1 | wc -l | xargs"
+    [ "$output" = "4" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with para 16 must be exact 34 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 16 | wc -l | xargs"
+    [ "$output" = "34" ]
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with para 255 must be exact 512 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 255 | wc -l | xargs"
+    [ "$output" = "512" ]
+}
+
+# Status checks
+@test "task1: Output with wrong CHILD_NUMBERS does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 0 "
+    [ "$status" = 1 ]
+}
+
+@test "task1: Output with wrong CHILD_NUMBERS does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 256 "
+    [ "$status" = 1 ]
+}
+
+@test "task1: Output with wrong PARAM does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' a "
+    [ "$status" = 1 ]
+}
+
+@test "task1: Output with to many para does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 2 3 4 "
+    [ "$status" = 1 ]
+}
+
+@test "task1: Output with standard CHILD_NUMBERS exits with 0" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 4 "
+    [ "$status" = 0 ]
+}
+
+@test "task1: Output with MIN CHILD_NUMBERS exits with 0" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 1 "
+    [ "$status" = 0 ]
+}
+
+@test "task1: Output with MAX CHILD_NUMBERS exits with 0" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 255 "
+    [ "$status" = 0 ]
+}
+
+