Assignment
In the real world, airports communicate with each other to ensure that if a flight takes off, it will be able to land shortly after it arrives. This communication is both a safety and a fuel economy measure, to avoid planes waiting a long time to land. We will add this feature to the simulator.
In this assignment you will implement a simple asynchronous message passing service and use it to allow threads to communicate with each other to simulate the inter-airport com- munication.
This assignment is intended to be done and executed in a Unix environment. You can use the csci3120.cs.dal.ca Unix server, a Mac (in Terminal), or your own Unix-based system, such as Linux, OpenBSD, FreeBSD, etc. This may also work in the Cygwin environment under Windows. Note: Your code will be tested on csci3120.cs.dal.ca.
Background
This assignment extends the functionality in Assignment 3. In the real world, the airport at which the flight originates has to request permission from the destination airport before the flight takes off. This ensures that the number of planes waiting to land at an airport is kept to a minimum and that airplanes do not burn too much (or run out of) fuel.
For this assignment you are asked to extend your program in the following way: For each time-step T (minute)
The rest of the simulation is the same as in Assignment 3.
To implement this functionality, it is recommended that a simple asynchronous message passing system be implemented (or used) to communicate between the threads. You will also need to have another list at each originating airport of flights waiting for permission to land.
Note: the sample solution to this assignment required an additional 80 lines of code in airport2.c and two additional source files comm.h and comm.c where the asynchronous message passing system was implemented. The latter was about 140 lines of code and implemented the following functions:
int comm_allocate() : allocate a new mailbox and returns the id of the mailbox. int comm_send(int id, void *buf) : asynchronously send a pointer to a buffer to mailbox id. (hint: the same solution passes around pointers to flight structs.
The input is the same as Assignment 3. Please see examples as shown in the provided test suite (tests_4.zip).
Processing rules are the same as in Assignment 3 in addition to behaviour described above.
The output format is the same as Assignment 3. Please see examples as shown in the provided test suite (tests_4.zip).
Same nonfunctional requirements as Assignment 3. Note: the starting code is either your solution to Assignment 3 or the sample solution, found on Brightspace.
To test your code, a test suite (tests_4.zip) is provided. Same test procedures as those in Assignment 3 are recommended.
Same conditions apply as in Assignment 3. A penalty of 10% will be applied if the assignment is done in Java or C++ instead of C.
You need only submit an electronic of your assignment. Submission must be done by 11:59 AM of the due date. Submission is done via Brightspace.
The assignment submission should be a single zip file (.zip) comprising the source code files that implement the simulator as well as the makefile and the runme.sh file.
Grading Scheme
The assignment will be graded on four criteria:
Concurrency “Is the solution maximally concurrent?”. This is determined by inspecting the code and ensuring for appropriate use of threads and locks. Concurrency is used as a multiplier for the rest of the code. Concurrency is graded on a 4 point scale:
(4) Solution is maximally concurrent e.g., uses threads appropriately and uses indi- vidual locks for each instance of a data structures.
(3) Solution is mostly concurrent e.g., uses threads appropriately but uses a single lock for all instances of a data structure.
(2) Solution is somewhat concurrent e.g., does not use threads appropriately or uses a single lock for all data structures.
(1) Solution is not very concurrent e.g., does not use threads appropriately and uses a single lock for all data structures.
(0) Solution is not concurrent.
The concurrency factor is multiplied by Functionality score because the base solution passes all tests.
Functionality “Does it work according to specifications?”. This is determined in an auto- mated fashion by running your program on a number of inputs and ensuring that the outputs match the expected outputs. The score is determined based on the number
of tests that your program passes. So, if your program passes t
tests, you will receive
that proportion of the marks.
Quality of Solution “Is it a good solution?” This considers whether the solution is correct, efficient, covers boundary conditions, does not have any obvious bugs, etc. This is determined by visual inspection of the code. Initially full marks are given to each solution and marks are deducted based on faults found in the solution.
Code Clarity “Is it well written?” This considers whether the solution is properly format- ted, well documented, and follows coding style guidelines.
If your program does not compile, it is considered non-functional and of extremely poor quality, meaning you will receive 0 for the solution.
Mark | |
Code Quality (Simulator)
Concurrency C = /4 Functionality (automated tests) Code Clarity |
/20
( × C)/20 /10 |
Total | /100 |
Programming Guidelines
The programs must be well commented, properly indented, and clearly written. Please see the style guidelines under Assignments or Resources on the course websit