CIS307: Homework 3: Communicating with Named Pipes and using Threads

Given October 7, due October 27 by 10pm.

1. The HMW_MAIN process has disappeared. Some of its duties are taken over by the server.
2. The server is created from the command prompt in its own window. It will have a user interface [see below].
3. Client processes are created from the command prompt either in their own windows or as background processes. They have no user interface. You will run at least four such client processes.
4. Communication between clients (the RAND_PROC processes) and the server (STORE_MANAGER) is not taking place using anonymous pipes, it is taking place using FIFOs (named pipes).
5. [All processes run on a single computer system.]

The STORE_MANAGER is started from the Unix shell and it is called with as command line parameter the path of a directory (in our case it will be "/tmp/"). The STORE_MANAGER creates a FIFO on which it will receive messages from clients. FIFOs have names expressed as file names. If you are user c307112, you will use "/tmp/cis307112/fifoSM" as name of the FIFO used by the server.
When the server receives a message from a client it creates a thread and gives the request to it. The thread will take care of this request, the Store Manager will not worry about this request (or this client) any longer. The server will make sure that there are never more than three threads active at the same time [i.e., while three are active it will not read from its FIFO]. [Beware: The counter that keeps track of the currently active threads is shared between the server and its threads. In fact the server reads from its fifo only when the counter is less than 3. Thus you will need a condition variable to help you here.]
The thread that carries out the request will send the reply to the requesting client using a FIFO created by the client. If the client has process id 6574, then the name of the FIFO will be /tmp/c307112/fifo6574.
The thread that carries out the request will assume that the read and update operations are slow. Thus it will simulate the "slowness" by starting the operation, sleeping a bit, and then completing the operation. Then it sends back the reply by writing to /tmp/c307112/fifo6574.. The thread then terminates.

Since a number of threads will be executing concurrently and sharing the table, you will need mutexes to enforce the appropriate mutual exclusions on a per table-entry basis.

[Implement the STORE_MANAGER first without using threads, mutexes, and condition variable, i.e. as a program that handles requests sequentially. Only after it works re-implement it using threads and mutexes. Only after that worry about the use of the condition variable.]

RAND_PROC and STORE_MANAGER will log to a shared log files all the messages that they send or receive.
The STORE_MANAGER has a user interface. It is a simple menu. One option lists the number of read operations completed, the number of updates completed, the number of reads and of updates currently in process. The other option terminates the STORE_MANAGER. The client processes should recognize this situation and each print out the number and type of operations it has completed.
Be sure that your program removes all the temporary files that it has created.