02152 Concurrent Systems        Fall 2008
OS Lab 1: Shared Process Memory

Home

Plan

Material

Purpose

Time and Place

Assistance for this programming lab will be available in the E-databar, Building 341, Room 015+019, Thursday, October 30, 15.00-17.00.

The PC must be booted into Linux

Preparations

Since the program skeletons will be given for most problems, no detailed preparation is needed. To understand the workings of the example programs, however, you may like to study the references below.

References

Experiments will be made using Java as well as processes written in C. You may like to study th man-pages of the system calls shmget, shmat, shmdt, and shmctl.

At www.cs.cf.ac.uk/Dave/C/node27.html you can find a more thorough description of shared memory in Unix.

You may study the Runtime class to see variations on how to start new processes (not threads!) from a Java program.

Note that as of Java 1.5, the ProcessBuilder class may be used to obtain finer control of the environment of created processes.

Instructions

You are first going to run a number of small programs to illustrate some aspects of IPC. You may then elaborate and combine these as the last point.

All the programs used in this lab be downloaded as a single zip-file: oslab1.zip

1. Running processes from Java

Java has a simple facility for creating a new process running a program while attaching to its standard input and output channels.

This is an example of IPC communication via pipes. The Java Virtual Machine creates the pipes and then creates a child processes by forking. The child process inherits the pipes and replaces these for the input and output (and error) filedescriptors before loading the program. Note that getInputStream() and getOutputStream() return the output and standard intput streams of the child process respectively.

• Load the program RunLS.java, compile and run it.
• Modify the program to run other commands or to take a parameter (in argv) that determines the program to run.

  Do not try to let the program start itself!!

2. Robustness

The C-program relay.c simply puts its input in brackets, line by line, until end-of-file is reached.

Its starts, however, by outputting its process identifier (PID) on the standard error channel for easy identification.

• Compile and run the relay program as usual

  gcc -o relay relay.c
  ./relay

• The Java-program RunRelay.java starts up the relay program and repeatedly inputs a string from the terminal and then passes it on to be processed by the repeater program.
• Compile and run the RunRelay code. Stop it by pressing Control-D (End-of-file) or Control-C (interrupt process) at the terminal.
• While running RunRelay, from another terminal window ry to kill the relay program by issuing the command

  kill -SIGKILL <pid>       or shorter      kill -9 <pid>

  where <pid> is the relay-program's PID as written on the terminal (can also be found by the command ps x).

  This command will send a SIGKILL signal to the process which will force the system to terminate it. This way, we can simulate a crash of the process.

We now want to make the small application more robust such that it can survive crashes of the relay program. This is a major reason for implementing an application by several processes.

• Rewrite the RunRelay program to restart the relay process if it terminates. Termination can be detected by input.readLine() returning a null pointer instead of a proper string.
• Demonstrate the robustness of your program.

3. Creating and deleting Shared Memory

The program memcreate.c creates a 64 k memory segment within the physical memory of the machine. The segment is identified by a key which is just an arbitrary 32 bit number (here the mnemonic 0xBAD02152 in hexadecimal notation). Be sure to use the same key in all your programs. Since memory segments are not automatically deleted you may otherwise fill up the main memory of the machine (although there is an upper limit on shared memory).

The program memdelete.c deletes a memory segment found by looking it up under a certain key.

• Compile [gcc -o memcreate memcreate.c] the create program and run it twice. The first time the memory segment is created. The second time, an error indicates that it is already in existence.
• Compile and run the memdelete.c program twice.
• Use more /proc/sysvipc/shm to extract kernel information about the shared memory segments (you may have to broaden your terminal vindow). Try to identify your own segment (now the key is in decimal: -1160765102).

4. Attaching to the segment

The program memread.c attaches to the memory segment, i.e. maps it into its own address space. Then it awaits some input (anything) and then reads the first 256 bytes of the memory segment and prints it.

Correspondingly, the program memwrite.c attaches to the memory segment, waits for a line of input and then writes it to the start of the memory segment.

• Compile memread.c and run it. Run memcreate if needed.
• Run memread, but before giving it any input, in another terminal window, write the command

  more /proc/<pid>/maps

  where <pid> is the process identifier that the program prints initially. This will show the current active virtual memory regions of the program. See that the memory segment is really mapped into the address space. Notice that rw-s indicates a read/write segment that is shared.
• Compile memwrite.c and run it. See the effect on memread
• Start both memread and memwrite in different terminal windows, and in a third window, see that they map diffent addresses to the shared segment. Obviously, structures linked with pointers cannot be used in a shared memory segment.

5. A heterogenous multi-process application

Combining the elements addressed above, write a small application consisting of a Java-program that starts up two concurrent sub-processes that share some memory. Then, the following should the be repeated:

1. A string is input from the terminal by the main process (Java-program)
2. The string is passed to the first sub-process
3. The string is passed to the second sub-process via shared memory
4. The string is passed back to the main program
5. The string is output at the terminal

Note that the synchronization of the two sub-processes must be controlled by the Java-program by a simple protocol over the pipes. (Alternatively, the processes would have to create and use SYS V semaphores.)

Hint: Create threads that print everyhing received on the error channels of the sub-processes. This enables debug messages to be sent independently of the protocol messages.

For this problem, you need not care about robustness.

Hans Henrik Løvengreen, Oct 27, 2008