You are tasked with writing a program in C language that will create, update, query and delete storage lockers. Each locker is represented as a process in the system which is created by your management process. Signals can be sent to the locker process to change the state of the locker outside of the management process. A locker process is made up of: Process ID (pid) : (unique to process creation) Locker ID : Creation order, Unsigned integer, starts at 1, always increments User Id : Unsigned integer Locked/Unlocked state Owned/Free state Two signal handlers (SIGUSR1 and SIGUSR2) The default states of a locker when created: Locked No Owner (Detached) A locker can be in 4 states, {Locked, Free}, {Locked, Owned}, {Unlocked, Free} and {Unlocked, Owned} states. Lockers are kept in a queue (or a data structure of your choosing) for reuse. Your program must be able to provide reporting on the current state of the lockers and handle commands from standard input. Each locker needs to handle a SIGUSR1 and SIGUSR2 signals. SIGUSR1 locks the locker and SIGUSR2 unlocks the locker. Your management process must be able to create lockers by using the CREATE command that will create a new process that your management program will manage. Helpful Note! If heap data has been allocated, then newly created locker should immediately free this upon execution. Your management process will also receive requests to decommission a locker (DELETE). Part of your inter-process communication protocol needs to incorporate a way to decommission a locker. You are to implement the following list of commands. These commands are inputted to standard input on the management process. The command description will typically (with the exception of QUIT) interact with a locker. Your management process will be interacting with the locker through an inter-process communication method of your choosing (pipe() or mmap() ). CREATE - Creates a locker DELETE - Decommissions a locker QUERY - Queries a locker and retrieves information QUERYALL - Queries all lockers and retrieve their information LOCK - Locks a locker UNLOCK - Unlocks a locker ATTACH - Adds an owner to a locker, gets locker at head of the queue DETACH - Removes an owner from a locker QUIT - Deletes all lockers and quits the program When the management process queries a locker it will print out information in this form (QUERY or QUERYALL): Locker ID: Lock Status: Owner: Output format for ATTACH, this gives a user ownership over a locker: Locker Owned By Output format for DETACH, this removes ownership of a locker from a user: Locker Unowned Output format for LOCK and UNLOCK: Locker Output format for CREATE: New Locker Created: Output format for DELETE: Locker Removed Important: You will have to define a simple communication protocol to communicate between these processes. This can be text messages over the pipe and parsing them or a binary protocol. You are able to choose the interprocess communication method. The following cases are not publicly tested In the event that you cannot create a new locker, your program needs to output: Cannot Build Locker In the event that a command utilises a locker id that does not exist, your program needs to output: Locker Does Not Exist If Attach is called and no lockers are unowned your program needs to output: No Lockers Available Recommended functions to use: pipe(), kill(), signal()/sigaction, fork(), wait()/waitpid() and dynamic memory functions. Potentially bitfields could be useful for the protocol. This assessment is building from concepts in Week 7, 8 and 9 Assumptions/Clarifications: If you attempt to lock a locked locker or unlock an unlocked locker, you will just need to relay the status regardless. You do not have to output that the operation did nothing. Owner id's are just inputted by your application and can be completely arbitrary but you can assume the maximum owner id is 255. When a DELETE operation occurs, unless the locker does not exist, it should remove the locker, regardless if it is owned by someone. QUIT should clean up and terminate all locker processes and quit without any output. You will need to ensure that you can create two way communication between processes. When executing QUERYALL, ordering is based on locker id order (Ascending) Your locker should not handle SIGTERM to terminate a locker. Locker id's continually increment Example: Example 1 CREATE Locker: CREATE New Locker Created: 1 Example 2 QUERY Locker 1: CREATE New Locker Created: 1 QUERY 1 Locker ID: 1 Lock Status: locked Owner: unowned Example 3 UNLOCK/LOCK: CREATE New Locker Created: 1 QUERY 1 Locker ID: 1 Lock Status: locked Owner: unowned UNLOCK 1 Locker 1 Unlocked QUERY 1 Locker ID: 1 Lock Status: unlocked Owner: unowned LOCK 1 Locker 1 Locked QUERY 1 Locker ID: 1 Lock Status: locked Owner: unowned Example 4 ATTACH: CREATE New Locker Created: 1 CREATE New Locker Created: 2 ATTACH 67 Locker 1 Owned By 67 ATTACH 20 Locker 2 Owned By 20 Example 5 DELETE: CREATE New Locker Created: 1 DELETE 1 Locker 1 Removed Example 6 QUERYALL example: CREATE New Locker Created: 1 CREATE New Locker Created: 2 CREATE New Locker Created: 3 QUERYALL Locker ID: 1 Lock Status: locked Owner: unowned Locker ID: 2 Lock Status: locked Owner: unowned Locker ID: 3 Lock Status: locked Owner: unowned