Laboratory Exercise Making use of lab4C.c for child process generation, you can create a program that will generate separate child processes to help dividing up a lot of processing tasks to be handled by each individual child. Effective division of labors among many processes actually forms the basis of cloud computing and big data processing, making use of the computing power of multiple processors. One common application to make use of abundant computing power is to perform simulation study. For simple questions concerning probabilistic results, mathematical analysis could be performed, e.g. the probability of getting 12 with two dice is 1/36 and the probability of getting 7 is 1/6. It is still possible to compute the probability of getting 40 with 10 dice. Likewise, one can compute the unconditional probability of playing for a 2/2 split in the bridge game with an analytic solution, but the conditional probability when some of the cards are known will deviate from the analytic unconditional probability. One way to estimate this probability is to simulate. In other words, generate many hands, say N, under the existing constraints and count the number of hands, h, satisfying the required condition. The required probability will then be h/N. Simple simulation could also be applied to study queuing systems, e.g. bank tellers serving customers, traffic congestion situation at Cross Harbor Tunnel. More complex computer simulation could be applied to study the infection model in epidemic study, typhoon trajectory prediction in meteorology, stock price change in financial technology, or pilot training in flight simulation. In this exercise, we are to study the impact of waiting queue building up for a service provided by the teller of a bank. Customers arrive randomly and queue up for teller service. Tellers take on customers and serve them, one after the other. There is also variation in the service time by each teller. We are to study how the queue is built up, and as a result, the impact on the waiting time of the customers. To simplify the scenario, let us assume that there is only one single queue, and only one single teller for the customers. You are given input data about the customer arrival pattern and the servicing pattern by the teller in the debug mode of the program and would generate the patterns in the simulation mode. In reality, random numbers are used to generate these patterns and are the key to simulation study. They are generated via a pseudo-random number generator, which is able to generate seemingly "random" numbers good enough for most practical applications. Yet, it is able to repeat the same sequence of numbers generated given the same seed. That is very useful in simulation study for cross-comparison and for debugging. The most common generator is the linear congruential generator, provided in standard C library, rand (). You are to make use of a pseudo-random number generator by controlling the seed, thus the outcome. The outcomes are deterministic and this would facilitate debugging. If you want the program to really randomly generate patterns, set the seed to be the current time (which would differ each time the program is executed; see time t above with the tv usec field). Data being used for the patterns can be generated randomly. For example, customer arrival events could follow a Poisson distribution, and the teller servicing events could follow a normal distribution. The standard queuing model usually assumes Poisson arrival and Poisson service in order to be analyzed mathematically, since Poisson events exhibit very nice mathematical properties. To achieve this, include the following code segment in your program, and make calls to the generator for the arrival and service patterns, after making appropriate modifications. Note that besides including the header file math. h, there is also a need to compile through linking to the maths library: cc 1m gen.c In this exercise, there are n child processes. The parent is just like a server that accepts user request and passes it to a child process to do the simulation. Remember that a child will know everything about the parent before fork ( ) is executed, so there is no need for the parent to pass in any argument to the child (and this simplifies the program design). The child should be able to extract its own part of the input data knowing its position from the argument list or from any stored array before fork () is executed. To facilitate program development and debugging, the program would be executed in different modes, as indicated by the first argument. Depending on the mode, other arguments should be interpreted accordingly. The modes to be provided include debug mode (D) and simulation mode (S). You can assume that there are no errors in the user input argument list. Do not forget to wait for the child to complete to avoid zombie processes. In the debug mode, there will be additional arguments for the two patterns, separated by the sentinel value of 1. Note that the length of the two patterns should be the same if the input is correct. Only one child process needs to be created in this mode. The first customer is assumed to arrive at time 0. In the simulation mode, there will be a second argument to indicate the number of child processes, n. This is followed by the t tasks. Each of the t tasks is specified by 4 arguments: the number of customers needing service, the seed to the random number generator to generate the arrival and service patterns, and then the arrival rate and service rate for generating the patterns. Each task is performed by each child in a round-robin manner. If there are more tasks than the number of child processes, some children would take up more than one task. The simulations are only performed by child processes, and the parent is not doing any real work. Each child will finally compute the average queue length and waiting time for generated customers within each task. In short, there will be 2+4t arguments in this mode, with n child processes being created. The first customer is also assumed to arrive at time 0 . In this exercise, the child processes are producing results independently. A better solution is to let each child report the result back. Then the parent process will consolidate together the results computed by the children, e.g. computing perhaps the mean and standard deviation of the waiting times and queue lengths. Remember that more attempts will lead to more accurate simulation. That is the concept behind cloud computing, based on the famous map/reduce paradigm. Inputs/simulation requests are divided up and mapped to different child processes; the parent then gets back the partial results and consolidates Processes Page 8 them via reduction. That would require the ability that the child processes can report the computed information back to the parent (i.e., ability of inter-process communication). These complicated arrangements are not required in this exercise. Hint: This is a highly simplified case for the discrete event simulation approach. All time units are in integers in this case. You could simply advance the clock for each time unit, and then check for the occurrence of the three key events: customer arrival (and queues up), customer completion (and departs), customer welcomed by the teller (and receives service). Once detected, appropriate actions can then be carried out for the specific event at that time unit. Please provide appropriate comments and check to make sure that your program can be compiled and execute properly under the Linux (apollo or apollo2) environment before submission. Note that you have to let all children execute together concurrently and must not control the output order from different children. The final results produced by all the children may be in any mixed order and you do not need to do anything to change the output order. Just let the nature play the output game for you. It is quite likely that those tasks with longer pattern files or more customers would execute more slowly. Sample inputs and outputs: Processes Page 9 Level 1 requirement: the child processes are created properly and can display the correct information about the given arrival and service patterns. Level 2 requirement: the unique child process can produce partially correct results in the debug mode. Level 3 requirement: the unique child process can product almost all correct results in the debug mode. Level 4 requirement: all child processes can work correctly under all the cases and produce correct simulation results in terms of average queue length and waiting time. Bonus level: you can handle the simulation with more than one teller. There can be several possible queuing strategies for the multiple tellers. Please explain briefly your adopted strategy. Name your program queue.c and submit it via BlackBoard on or before 3March2023