Programming Assignment 6: Implementing IPC Mechanisms Solution

Introduction




The last two programming assignments have made heavy use of the RequestChannel class, which was pre-written and given to you along with the dataserver code so that you could focus on learning synchronization techniques. In fact, it was possible to complete both PA4 and PA5 without even looking at either dataserver.cpp or reqchannel.cpp.




If you did look at them, you may have noticed that the RequestChannel class uses a mechanism called \named pipes" or \FIFOs" to communicate between the two sides of the channel. However, FIFOs are only one of several di erent IPC mechanisms, each of which have their own particular uses that make them suited to particular applications. In this programming assignment, we are going to expand our toolbox by learning about 2 \new" IPC mechanisms in addition to named pipes: message queues and shared memory, where the latter would in turn use Kernel Semaphores.







Background




Message Queues




While pipes provide a byte stream between two processes, message queues allow for the exchange of messages between processes. There are library functions (POSIX library, not STL) for message queue opening/creation, sending messages, receiving messages, closing the message queue, deleting the message queue, and modifying the message queue’s attributes. You may be able to use default attributes for this assignment, but those defaults vary by system. Visit the man pages for System V IPC (not the POSIX IPC) for how to check and set default message queue attributes.







Shared Memory




Up until now there have been IPC mechanisms to provide byte streams and message passing, but what if something a little more versatile is needed? Shared memory is exactly what it sounds like: a segment of memory that can be read and modi ed (depending on its con guration) by multiple di erent processes. You will notice that there are no system calls for reading and writing the shared memory segment. This is because a shared memory segment is semantically identical to any other memory segment, such as can be obtained from malloc, except for the IPC and synchronization considerations. One can read and modify it using memset, strcpy, memcpy, or just about any other memory-reading/writing operations. This brings in synchronization concerns between the writer and reader, which we will have to solve using Kernel Semaphores.



















1
CSCE 313 Fall 2018







Kernel Semaphores




You are already familiar with the concept of semaphores from PA4 and PA5, and even had to write your own. However, that semaphore was only \process-local" or \thread-shared," since it was allocated within the address space of a given process. What if two di erent processes needed to synchronize on the same semaphore, a \process-shared" or kernel semaphore?




For this programming assignment, part of what you will need to do is ll in the methods of the KernelSemaphore class. KernelSemaphore implements the familiar Semaphore interface but is distinct from the process-local semaphore from PA4 and PA5.







The Assignment




Code




You have to start o of your code from PA4. We are assuming that you have a working PA4. If that is not the case, please contact us for a working version of PA4 (if you get a working PA4 from us, you cannot later make up by submitting a late PA4). Please do not start based on PA5 because the select() at the heart of PA5 will not work with either shared memory or message queues.




You then have to make up 3 versions of your PA4 each using a separate IPC-method-based request channels: FIFO, message queue, and shared memory. Call these versions PA6 FIFO, PA6 MQ, PA6 SHM, respectively. You should have an abstract RequestChannel class and 3 sub-classes:







FIFORequestChannel MQRequestChannel SHMRequestChannel




Here, the rst one FIFOReqeustChannel would be taken directly from PA4 and you need to implement the others. The API of base RequestChannel class should be as follows:




class RequestChannel f




public :


fSERVER SIDE ,
CLIENT SIDEg S i d e ;
typedef
enum
typedef
enum
fREAD MODE, WRITE MODEg
Mode ;
/* CONSTRUCTOR/DESTRUCTOR
*/


RequestChannel ( const s t r i n g name ,
const S i d e s i d e ) ;
~ RequestChannel ( ) ;




virtual
s t r i n g c r e a d ( ) = 0 ;








/* Blocking
read of data from the channel. Returns a string of
characters
read from the
channel. Returns NULL if read failed. */
virtual
int
c w r i t e ( s t r i n g
msg )=0;


/* Write the data to the channel. The function returns
the number of characters written to
the channel. */










g;














2
CSCE 313 Fall 2018







You will also need KernelSemaphore class for a properly functioning SHMRequestChannel, where the semaphore API should look like the following:







class KernelSemaphore f

private :




/* INTERNAL DATA STRUCTURES */




public :




/* CONSTRUCTOR/DESTRUCTOR */




KernelSemaphore ( int v a l ) ;




KernelSemaphore ( ) ; // make sure to remove all allocated resources



void P ( ) ; /* Acquire Lock*/




void V ( ) ; /* Release Lock */




;






0.1 Compiling and Running Your Code




There should be only 1 makefile to compile everything together.




Take an additional runtime argument option \-i" which should get one of:




\f" for FIFO




\q" for message queue \s" for shared memory




The following is an example command to run PA6:







./ client -n < requests / person -b < bounded buffer size




-w < number of request channels -i <f | q |s




You must resolve the derived type of RequestChannel class in the runtime using polymorphism and run-time binding in C++.




0.2 Clean Up




You must clean up all IPC objects from the kernel memory and all temporary les you created for doing ftok(). Checking the /dev/mqueue and /dev/shm directories (or alternatively, running ipcs command in shell) will aid you in this clean-up process. In addition, you should clean all heap-allocated objects.




Report




Gather timing data on the same set of n; b; w arguments on each of PA6 FIFO, PA6 MQ, and PA6 SHM.




Present a performance comparison of the di erent IPC mechanisms based on this data, and attempt to provide explanation for any di erences and similarities.




Present the results in separate graphs using PA6 FIFO (i.e., PA4) as the baseline for comparison







3
CSCE 313 Fall 2018







What is the maximum w and thus the max number of RequestChannels that you can use for each IPC? How much more can you go beyond the limit in PA4? (recall that the limit imposed by how many le descriptors each user can have. Now that we are not using le descriptors for MQ or SHM, has that situation changed?)




What are some of the limits encountered by each class, either due to the speci c implementation or to operating system limitations, and how does the program behave when it encounters them?




Describe the clean-up activity you have done for each IPC




Bonus worth 12 points




Using only one MQ object for all the request channels: 4 pts




Using only one shared memory segment for all request channels: 4 pts




Using minimum number of temporary les (needed for calling ftok() function) for each request channel: 4 pts




What to Turn In




Turn in a single zip le PA6.zip containing the report, all the class les (separated into .h and .cpp) and a makefile. Note that the same makefile should build all request channel versions (FIFO, MQ and SHM).

































































































4