Having decided that there are essentially two parts of the application, a real-time synthesiser and a GUI, it seems to make sense to divide the processing into two. One process will be responsible for the audio synthesis; the other for the mouse- and window-related processing.
Linux, like most unices, provides two different methods for inter-process communication (IPC). The first is channel-based: sockets, pipes and so on. This kind of IPC has many advantages: one can easily map the processes onto different machines connected by a network, and synchronization is easily arranged, because a channel can be set up to block in an efficient, non-polling manner until data arrives.
However, the Prism application has two processes which essentially operate asynchronously. Essentially, the resynthesiser has to keep on running and producing audio samples regardless of what the user is doing with the mouse. For this reason, the second method of IPC, shared memory or System-V IPC, has been used. System-V IPC also provides methods for process synchronisation: the semaphore. One can use raise, or wait on a semaphore. Think of it as a special kind of variable which behaves as follows. If one or more processes waiting on a semaphore, raising it enables exactly one of those processes to proceed; if no processes are waiting, then the value of the variable is incremented. Waiting on a non-zero semaphore decrements its value but allows the process to continue immediately; waiting on a zero-value semaphore adds the current process to a (possibly empty) list of waiting processes, pending the semaphore being raised by another agent.
Semaphores are used in shared-memory situations to implement mutual exclusion locks, and prevent update anomalies where several processes simultaneously attempt to modify a shared data structure. However, Prism uses only two processes accessing the shared memory block: the GUI is a producer because it is supplying control parameters, and the synthesiser is a consumer because it uses them to generate audio samples. Since there is only one producer and one consumer, there is no need to use semaphores as access arbiters. In fact, advantage is taken of the shared memory IPC to permit the producer to provide a set of ``magic'' parameters which change according the the user's gestures.