Objectives: - To develop multiple producers - single consumer application. - To implement the bounded buffer as a circular queue. References: - Linux man pages "man pthreads" and "man sem_overview" - Linux System Programming 2d ed., Robert Love, O'Reilly 2013 (CATS/CSE5031 - Home / Resources / References) - The GNU C Library Reference Manual 1 Section A. Project Definition and Implementation Phases A.1 Problem Statement The project aims at implementing the multiple producers - single consumer application depicted here after. Producer tasks perform the following transactions and log the result of their processing in a shared buffer: pay - emulates periodic deposits of the salary to a bank account. atm - sketches withdrawal or deposit transactions from/to a bank account. bill-emulates payment order/tax withdrawals from the bank account. Consumer task arch - retrieves producers' transaction records stored in a shared buffer, archives them in a log file. Implementation of the application scenario requires the resolution of the following synchronization problems: Producers run into race condition when they access the bank "account". Producers and the consumer run into race condition when they access the "shared buffer". Producers and the consumer should coordinate their activities to use the "shared buffer"; that is, producers can store their log record if there are available slots or consumer can retrieve log record if one is stored. A.2 Implementation Constraints i) Development Environment You are asked to develop the project in C language using: POSIX Pthread API to create threads, and POSIX semaphores to resolve synchronization problems (race conditions \& coordination). ii) Simulation of Processing Overheads You will use the "sleep (seconds)" function defined in "unistd.h" to emulate processing overheads. This call releases the CPU(s) that will be immediately dispatched to other threads waiting in the OS ready queue. iii) Application Termination Protocol Producers should run while "atm" is active, then terminate after completing current transaction. Consumer should run while a producer is still active; then terminate after displaying all the records logged in the "shared buffer". iv) Modelling Data Repositories To ease the application development and focus on the synchronization issues, you will implement: the bank "account" file, as a shared global variable; the "log" file, as the pseudo-terminal "pts/1"; the "shared buffer", as a circular queue: - resolving race conditions between concurrent threads; and - providing atonic operators to store/ extract records and coordinate producers and the consumer activities. A.3 Application Operational Context Implementation constraints outlined in Section A.2 yield in the operational context depicted here after. A.4 Implementation Phases To cope with the synchronization problems and ease your testing and debugging processes, you are asked to develop the project in three parts. i) In Part 1 you will implement the single producer - single consumer scenario and program the "atm" and "arch" threads, referring the prototype C program "prj6ref.c" provided in the CATS portal. ii) In Part 2 you will add the producer "pay" and compare your results versus the behavior and outputs of the reference code "solp2" provided in CATS portal. iii) In Part 3 you will add the last producer "bill" and compare your results versus the behavior and outputs of the reference code "solp3" provided in CATS portal. A.5 Development Support To assist you in the implementation of the multiple producers - single consumer scenario, reference C programs are provided at the course CATS portal. Log on the Udt VM using the "std" account and create the "/home/prj6" folder. Download "pri6ref.c", "solp1", "solp2" and "solp3" files stored under Resources / Project Appendices / Prj6 folder; and copy them in the "pri6" folder. Check "prj6ref.c" attributes and remove the "x" permission, if any, with the "chmod a-x ".c" command. Set the "x" permission for executable files, if needed, with the "chmod a+x s" command. In Part 2 you will add the producer thread "pay" and compare your results versus the behavior and outputs of the reference code "solp2". C.1 Implementation Guidelines for Part 2 a) main thread should be updated to include the "pay" thread; as such it has to: open the pseudo terminal "/dev/pts/2"; define state variable for "pay"; create and a wait for the termination of all the threads; close the pseudo terminals. b) atm thread remains unchanged. c) arch thread: should be updated to wait the termination of all the producers. d) pay thread: displays its outputs on the pseudo terminal "/dev/pts/2" considering that it will share it at Phase 3 with the "bill" thread; while "atm" is active: deposits every 12 seconds a fixed amount e.g. 10 to the account; displays the transaction on"/dev/pts/2; logs the transaction C.2 Testing Part 2 You are advised to test your application: without entering a deposit or withdraw and observing how the "pay" thread updates the account alone; then, using the "atm" thread along. Verify at the completion that account has been correctly updated Compare the outputs and behavior of your application versus "solp2" and take corrective actions if necessary. C.3 Reporting Part 2 i) Run the application; perform a deposit and wait until "pay" updates the account. ii) Take the screen shuts of "/dev/pts/1" and "/dev/pts/2"; save the captures as "p2pts1.jpg" and "p2pts2.jpg