Managing Your IPC Structures

IPC Structures?

Yes, IPC structures! IPC stands for inter-process communication, and the structures most commonly used are semaphores and shared memory. They are fairly easy to use, and very easy to misuse. Since both are in limited supply, one user's mistake can prevent him and others from getting useful work done. Therefore, it is necessary that each user take responsibility for his own IPC structures and know how not to harm his productivity and that of other users.

Shared Memory

Let's start off with shared memory, since it is the simplest structure to understand. Shared memory is just what it sounds like: a block of memory which can be shared between processes. Like other IPC structures, when you create a block of shared memory, you assign it permissions, just as you would a file using chmod.

Okay, say you've figured out that your program will need some scratch space in memory so that its processes can pass data back and forth. Your first attempt at this is to create an array, then fork the process. Both processes should now be able to access this array, right? Sure, but they each have their own copy of the array. That won't do. After thinking about it some more, shared memory seems like a good idea, so you create a block of it. Now what? There seems to a problem: a block of memory can reside in one process's address space, but definitely not in multiple processes' address spaces, and having address spaces overlap or be non-contiguous is probably a bad idea. How is this going to work?

The answer is that the shared memory does not actually reside in any process's address space. Each process that wants to use the shared memory must therefore reserve a block of memory in its own address space of the same size, and tell the operating system to map all of those memory addresses to their corresponding addresses in the shared memory block. This is referred to as attaching the shared memory to a process's address space, and the end result is an array that behaves as if it were shared. Now you can create an array, create a block of shared memory, attach the array to the shared memory, then fork a new process, and the two processes will be sharing the array as expected.

Semaphores

You can start off by thinking of a semaphore as a file that contains a single unsigned int. As with shared memory, when creating a semaphore, you assign it file-like permissions. You can assign any unsigned value you like to a semaphore, and other processes may access and change this value, assuming that the permissions allow it, and that they know the ID number of the semaphore (which you assign when you create the semaphore). The catch is that rather than assigning a precise value to the semaphore, you can only add or subtract from the current value (often called 'upping' and 'downing', especially when incrementing and decrementing by one).

So is a semaphore just an unsigned int that can be shared by multiple processes, right? Yes, but it has one more interesting feature. When a process tries to decrement a semaphore such that the resulting value would be negative, the process blocks. If you are unfamiliar with the term, it simply means that the process is put to sleep until a condition is met. The condition, in this case, is that the value of the semaphore is great enough that the process can decrement it without making the end result negative.

As you may have already figured out, it is very easy to write a program which creates a semaphore, forks into two processes, then does something such that each process is blocking, waiting for the other to up the semaphore. This is called deadlock, and typically the only way out is to kill the program. However, this leaves the semaphore hanging around. Since you have a limited number of them at your disposal (and the system has an absolute limit as well for all users), it is in your best interest to destroy semaphores that your misbehaving programs leave behind.

Another thing to watch out for is the permissions you assign to the semaphores you create. It is very easy to create a semaphore with 000 permissions; that is, you yourself cannot see or manipulate the semaphore you just created. It is recommended that you use 644 as your permissions. This gives you read/write, and others read access to the semaphore.

Removing All of Your IPC Structures

To look at the IPC structures currently in use, type ipcs at the command prompt. It will show all of the semaphores which you have at least read access to. If you notice that someone is using a few too many semaphores, you might consider asking them to remove them. Otherwise, ask a consultant or staffer to help you.

If you are the one with too many semaphores, there's a quick way to get rid of them. To quickly remove all of your IPC structures, first make sure you aren't running any programs which use IPC, because this is going to screw them up royally if they are running. When you are ready to wipe all of your shared memory and semaphores (even if you created them with 000 permissions and can't see them using ipcs), type removeipc at the command prompt. (If that doesn't work, make sure /usr/local/share/bin is in your path).