Unix/Linux Semaphores and Shared Memory Implementation for Airline Reservations

Task

In this assignment, you will implement several programs with Unix/Linux semaphores and shared memory to handle airline reservations taken by different agents connected to the “Fall-OS” airline’s central computer.
Suppose each travel agent is represented by a process and the body of the process consists of all the reservations/ticketing made by that agent. An agent can make reservations, ticketing (selling of seats), cancellation of reservations/ticketing. Two or more agents may be doing the same transactions at around the same time. Obviously, reservations/ticketing to the same flight must be performed atomically (mutual exclusively). If an agent tries to reserve/ticket a seat that has already been taken, then disallow this action and print a “seat taken” message. If a transaction tries to operate on a non-existent flight or seat, print an appropriate error message.
To ensure these concurrent operations yield correct results, you are to use Unix semaphores to control access to flights, which are stored in shared variables. Each individual flight should be controlled by at least one semaphore. Also, the information database for each flight is stored in shared memory.
To simulate (1) the transmission delay between the airline’s central computer and an agent’s computer terminal and (2) the processing of each transaction, the first six lines in the body of each agent specify the required total execution time (in milliseconds) for each of the six operations performed at that agent. In your implementation, each specified time is the length of the critical section for the corresponding transaction.

You don’t need to reserve before you ticket a seat. The ‘wait’ transaction is like ‘reserve’ except that ‘wait’ will wait-list the passenger for the selected seat if this seat is currently not available, and is like ‘ticket’ if this seat is currently available. The agent with this ‘wait’ transaction continues to perform the next transaction regardless of the availability of the selected seat. Note that if this seat is currently unavailable and later becomes available as a result of a ‘cancel’ transaction by another passenger, then this seat will be sold to the passenger who first executed the ‘wait’ transaction in case there are two or more passengers waiting for this seat. The ‘waitany’ transaction is like ‘wait’ except that at the end of the execution of the agent executing this transaction, if no one cancels the requested seat, then the airline reservation system assigns an available seat in a lowest-numbered row (closest to the front) on this flight.
You can cancel a seat only after you have reserved/ticketed it.
Each transaction is followed by the keyword deadline and its numerical value (in milliseconds, relative to the start time of the process or process creation time) for completing this transaction.

1. Each Agent has the ability to cancel a seat on a flight for a passenger that was reserved by an other agent.
2. This output is specifically for FIFO , the EDF/LLF can be easily worked out on a paper from this solution.
3. Maintenance of a global timer becomes critical in managing the deadlines and deadline misses.
4. The output shown here need not be replicated in the exact same fashion. However, the summary as to when an action finishes and whether the deadline was met/missed has to be reported.
5. " Implement three versions: (1) the first without considering passengers’ deadlines; (2) the second with EDF scheduling of the transactions; and (3) the third with LLF scheduling of the transactions,where the remaining computation time of a process is the sum of the computation times of this process’ remaining operations." -> this part of the assignment simply indicates the following:
  a. 1st part indicates FIFO implementation with deadlines considered. For instance, for the given input: sequence of actions have to look like <Agent-1, Agent-2, Agent-1, Agent-2,.....> until completion.
  b. 2nd part indicates EDF implementation of the same. These agent actions will then be sorted based on the deadlines provided.
  c. Similarly for LLF, these actions need to be sorted on the Laxities. i.e., (Ddl-Execution time).