UMBC CSEE |
Computer Science & Electrical Engineering
University of Maryland Baltimore County
Baltimore Maryland 21250 USA
voice: 410-455-3500 fax: -3969
|
UMBC|
CSEE
|
Project 2: InterProcess Communications Using Shared Memory
(c) 2000, Gary L. Burt
Assigned: 1 Nov
Due: 15 Nov
UPDATE -- 8 Nov
You do not have to use the exec functions to run programs child1b and
child2b. That will make it easier for the children to work with
the shared memory.
UPDATE -- 13 Nov
You do not have to read the file into child1 a line at a time. You must
output the data a line at a time, though!
UPDATE -- 13 Nov
The Office of Information Technology reports on the problems of
running out of shared space for shared memory:
"Looked at linux1 & linux2... Linux2's shm segments were all maxed
out by
one user. linux1 seemed generally ok.
You should remind "everybody" that when they're debugging their
apps, they
should do an "ipcs" every once and awhile, and "ipcrm" segments that
aren't in use anymore. My guess is that their programs are crashing
and
things aren't getting cleaned up."
Project Goals
The goals of this project are to learn the basics of
InterProcess Communication (IPCs) using shared memory instead of pipes as was
done in Project 1.
The Project
You are to redesign and reimplement project 1 which a simple set of
processes, where a parent creates two
children. The two children are to communicate with each other via shared
memory.
Specifications
Parent Process
The parent shall do error checking and abort on any error condition after
printing an error message.
The parent process shall accept one argument from the command line,
which is the name of an ordinary ASCII text file. (This should be in
argv[1].) The parent shall create a shared memory buffer and create the
two children. It does not matter if the child or parent open the file
given in command line.
It shall print out its process ID and the PID of each child. When the
parent completes successfully, it shall print out the message:
This was a successful project.
Child 1
After child 1 is created, child 1 shall attach to the shared memory
opened by the parent. Child 1 shall then run
another program (called child1b). The child1b process shall read one
line at a time from the file that was specified in the command line.
(Note: The child can open the file if desired.)
Select a file that has less than 4096 bytes in
it for this project!
Child 2
The second child shall attach to the share memory opened by the parent.
It shall then cause a third program (child2b) to execute. Child2b shall
take the lines out of the buffer and
print the lines on the standard output (which is the terminal).
The output shall be in the form of:
<PID> lineNr (nrBytesRead): line
An example would look like:
<10526> 0 (13): root:x:0:root
(The actual line of text from the file for this example (/etc/group) was:
root:x:0:root
Grading
Make sure you have read the general information on programming projects.
Approximately 20% of your grade is for documentation, and the remainder
is based on how well your project works. You should describe your design
and implementation at the beginning of the project; this initial
description is worth 15% of your grade. Describe any non-trivial data
structures you have used, and briefly say how each relevant routine
acts on those data structures. The description should be about a half-page
long. Do not ramble incoherently, and do not simply echo the
specifications given here. The standards for documentation are:
Coding Standards
Indentation Standards
You must do the project described here. Every time the requirements uses
the word "shall" is an item that you will get points for if you did it or
loss points if you did not do it! Doing some other similar or dissimilar
project, matter how difficult or clever, may be worth 0 points. This is
not a group project; please do your own work, and be careful about sharing
your code. It is OK to discuss design issues, but in your documentation,
you should give credit to your sources.
What to turn in
You shall make a tar file out of your source code files, including
your Makefile. You shall mail the tar file to the TA for grading.
Hints and Tips
- To get started, you should read your text's discussion of sys calls, and then the
man pages for fork, execve, execvp, execl, dup, dup2, wait, pipe, perror,
read, gets, write, and for any string functions
you might want to use. ("man string" will bring up a summary page on the basic
string functions.)
- The functions execve and execvp take an array of strings as their
arguments. This array is similar to the argv[] array passed to C programs.
When you create this array, it is important that the end of the array is marked
with a null pointer (Not a null string!); for example if there are k string
pointers in your array args, you would set args[k]=0.
- You might need some or all of the following "include" files.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <strings.h>
- You should develop your code in a series of stages:
- You should be able to do this project on any system that is POSIX
compatible, including LINUX, SGIs and Sun workstations. However,
the "official" platform for this project is linux.gl.umbc.edu
- This does not need to be a long project; if you have more than about
five pages of code you might want to think carefully about your
overall design.
Simple Pipe Sample Program
This will be handed out in class.
UMBC |
CSEE |