We need to add codes from server(kiosk) to sale tickets for the show.Most of codes are pre-built, and I added codes also.But where I got stuck is that kiosks oversell tickets and I also need to use Banker's algorithm to prevent deadlock.I have attached descriptions, original files and my edited file. The file we need to add codes is oshow.c
Fall 2019 CS 370 – Operating Systems Programming Project #3 DUE: Nov 26th (Tuesday) 11:59pm Total 120 points Note: submit your code/solution on WebCampus by the due date. Late submission must indicate how many allowance days you are going to use. 0. General instructions As with project 1 and 2, your work should compile/execute on cardiac. You are free to work on this project on a different machine, but you must test your code on cardiac. You need to turn in your work (i.e., code, binary, makefile, script, notes, etc) in the directory as follows: proj3/ You should make a tarball for the entire project and turn in the tarball with a descriptive name. E.g., $ tar –cJvf cs370_proj3_MyName.tar.xz ./proj3/ A special 'drop box' directory has been set up on cardiac. You can now just copy your work (i.e., tarball file) into that directory from shell command prompt. The directory is located at /home/cs370-1003/ (This directory is write-only – you only have write permission). After you create your tarball file for your project, you can just copy the tarball file into the directory as shown below: [student@cardiac ~]$ cp cs370_proj3_StudentName.tar.xz /home/cs370-1003/ [student@cardiac ~]$ _ (Make sure you have your full name as part of your tarball file name.) You then need to log in to WebCampus and submit a note there, which should contain: The name of the file you submitted The late-days you have used in this project and the remaining late-days Special instruction, if any, that I should know to compile/run your program You may add any additional information to the note regarding your project. It's important for you to submit the note on WebCampus as this will allow WebCampus to record that you have submitted your project. In case you need to update your submission, you can just overwrite the old file in the directory. If you don't remember old file name, that’s OK, I'll use the latest one that's submitted before the deadline. Just make sure you have your name as part of the tarball file name. Also note that both tarball on cardiac and the note on WebCampus should be submitted before the deadline. The timestamp of tarball file on cardiac should be before the deadline (or within extended deadline if you're using late days). I'll be a bit reasonable for the note on WebCampus, so I'll tolerate a few minutes late for the note. 1. OShow ticket booth: multithreaded handling of limited resource (120 points) Purpose: to understand thread synchronization in an event-driven workflow using standard C and pthread library in Linux. To experience resource allocation issue. Description: Your task is to write a ‘server’ program handling ticket sales using threads. Imagine we are going to sell tickets for a Las Vegas show called ‘OShow’. The theater has 10 kiosks for ticket sales. Each kiosk connects to a central server, on which your ticket sales program is running. The show has 4 different seating categories: Floor, Mezzanine, Balcony, and Box. The number of seats available and prices are as follows: Floor Mezzanine Balcony Box Total seats 110 80 90 40 Price $210 $130 $100 $230 Patrons can come to any of the kiosks to purchase tickets. Once a patron comes up to a kiosk, the purchase transaction proceeds as follows: OShow Theater 1) The patron first asks for a price quote for a seating by showing “QUOTE_ME_
” message. 2) If seat is available, the kiosk replies by showing the price. If seat is sold-out for the requested seating area, it replies by “TICKET_SOLD_OUT” message instead of price quote. 3) If the patron receives price quote, the patron can either accept to buy the ticket (by showing “I_ACCEPT” message) or reject the quote (by showing “I_REJECT”). In the case the patron received sold-out message in 2), the sales transaction is completed at this point. 4) The kiosk responds to patron’s decision made in 3) by sending out a unique ticket sequence number back to patron in case “I_ACCEPT”, or a special message “REJECT_ACKNOWLEDGED” in case “I_REJECT”. This completes the sales transaction. Note that the kiosk must deliver a ticket that’s quoted and accepted. This means at step 4) we don’t have message like “sorry, the ticket I quoted you just went away”. It must deliver unique ticket sequence number. Figures below illustrate the above transaction protocol. Client (patrons.c) 1) Message: QUOTE_ME_FLOOR (1) 2) Message: 120 (floor ticket price) 3) Message: I_ACCEPT (11) 4) Message: ‘2343’ (ticket sequence number) Server (oshow.c) Figure 1. Messages sent when client successfully purchases a floor level ticket. Figure 1 shows the sequence of messages when client purchases a floor level ticket. Figure 2 illustrates the case when client reject the price quote. Figure 3 shows the case when ticket for a particular seating area has been sold out. Client (patrons.c) 1) Message: QUOTE_ME_BALCONY (3) 2) Message: 110 (balcony price) 3) Message: I_REJECT (12) 4) Message: REJECT_ACKNOWLEDGED (-2) Server (oshow.c) Figure 2. Messages sent when client quoted a price for balcony seat, but rejected the quote. Client (patrons.c) 1) Message: QUOTE_ME_BOX (4) 2) Message: TICKET_SOLD_OUT (-1) Server (oshow.c) Figure 3. Messages sent when client asks for a quote for a seating area that has been sold out. Once a TICKET_SOLD_OUT message for a particular seating category is notified at a particular kiosk, patrons will not ask for quote anymore for that category at that kiosk. (the kiosk hangs a sign like ‘Balcony sold out’). Once kiosk knows that all the four seating categories are sold out, the kiosk shuts down and communication lines will be closed (see details section below). We assume that patrons can buy only one ticket at a time. Also, the show is very popular – there are infinite demands for the seats so the show will be sold out always. Patrons are also very patient, meaning that they can wait indefinitely for a price quote. In other words, after step 1), the kiosk can take arbitrarily long time to show quote at step 2). This is important because, if not careful, you won’t be able to guarantee the delivery of a ticket quoted when tickets are almost sold out. Be careful NOT TO OVERSELL the tickets. Details: The above description is simulated by two programs: ‘oshow’ and ‘patrons’. Oshow is the multi-threaded server program that handles ticket sales. Oshow spawns 10 threads. Each thread represents one kiosk. Your task is to implement the oshow program. The patrons program simulates customers buying tickets by interacting with oshow via named pipe (described below). I provide the patrons program. The IPC (Inter-Process-Communication) needed in this setup is satisfied by using ‘fifo’ also known as ‘named pipe’. ‘fifo’ allows you to create a file system entry that is not actually backed by a physical file in storage: the entry is used as a means of communication between two processes. Once you have a fifo entry in the file system (e.g., $ mkfifo my_fifo creates ‘my_fifo’ in current dirctory), then a program A can open the file read-only, then a program B can open the file write-only. What program B writes to the file will appear at program A’s reads. For details, see man pages for fifo(7), mkfifo(1), and fifo-specific sections on open(2), read(2), write(2). Unlike socket, fifo/named pipe is half-duplex: you need two fifos to implement bidirectional communication. Each kiosk-patron connection is thus represented by a pair of fifo: - kiosk-client[0-9] is used for messages sent from patron to kiosk - kiosk-server[0-9] is used for messages sent from kiosk to patron This means that you need to create total 20 fifos in your working directory. To help you set up your directory, the Makefile included has a target named ‘fifos’ which creates all 20 fifos in current directory. (i.e., “$ make fifos” command in shell will create the fifos.) The format of message packets sent through the fifos is very simple: each packet is just 4-byte signed integer in little-endian. Interpretation of the value depends on context (See the figures above for example). Following lists #define s symbols for special values: // messages from client (patron) #define QUOTE_ME_FLOOR (1) #define QUOTE_ME_MEZZANINE (2) #define QUOTE_ME_BALCONY (3) #define QUOTE_ME_BOX (4) #define I_ACCEPT (11) #define I_REJECT (12) // special values from server (kiosk) #define TICKET_SOLD_OUT (-1) #define REJECT_ACKNOWLEDGED (-2) When you work on the project and want to test and debug, you need to execute the server (oshow) and the client (patron) programs concurrently. This means that you will need to set up two ssh terminal screens so that you launch oshow in one screen and patron on another screen. You may want to have third screen just to code/debug. Or, you can use some terminal management programs such as ‘screen’. You don’t have to modify patron.c . Of course you can change patron.c if you wish, for example, when you want to debug your oshow code and you want to add more test routines/debug outputs on patron.c . However, make sure that your final code works correctly with the original patron.c . What to turn in: - Your source code named oshow.c with DESCRIPTIVE/HELPFUL COMMENTS - Your binary named oshow - Makefile Grading: - 40 points for demonstrating you put enough efforts in coding (thread creation, open/read/write on fifo, using mutex/condition variables,