/**********************************************************************/ /* Note : Extremely short intro IPC mechanisms and process control. */ /* By : Albert van der Sel */ /* Version: 2.0 */ /* Date : 31/05/2009 */ /**********************************************************************/ This (extremely) short note, introduces the concepts of Inter Process Communication, or IPC, shared memory, and process / resource control, which can (among others) be realized using semaphores. What is "shared memory"? ======================== Shared memory: It's an area of memory accessible to multiple processes. You may also look at it this way: It's related to inter-process communication (IPC), i.e. a way of exchanging data between programs running at the same time. It's is an area in RAM, which multiple processes can access. Shared memory provides a fast way for processes to pass large amounts of data to one another. When you think of IPC mechanisms, one would quickly think to mechanisms like "message queue's" or "pipes" etc.. Shared memory is also a way for programs (processes, threads) to exchange data, although some folks do not include it in the IPC list of mechanisms. Well, shared memory just looks like "a memory area", while rpc, pipes etc.. looks more like "actions". Many processes use shared memory. But it is very prominent with Database software. You probably know (or will see) that DB software like Oracle, always use a shared memory area. Indeed, many processes need access to that area. One thing remains though: shared memory is confined to the "same one machine" (although something like "distributed memory" exists). So, if you regard it as IPC, it's ipc for this machine only, while other ipc mechanisms can act between local and remote partners. What is "IPC"? ============== Interprocess communication (IPC) is the transfer of data among processes. It's a way that's makes communication possible between processes. Also, "remote method invocation", or calling methods/procedures of remote objects, is also a form of ipc. IPC might be involved with communicating between parents and children, or between “unrelated” processes, and even between processes on different machines. As a very basic example, you might consider the following command as (one way) communicating between programs: $ ls | more Here, the "ls" program writes it's output to the pipe "|", while the "more" program reads from the pipe. Some commonly used ipc mechanisms are: - message queue (message passing) - sockets - pipes, fifo - RPC - shared memory (see above) In many documents you might find other protocols listed like for example CORBA. But CORBA is an elaborate framework, and indeed, a building block is "Remote Method Invocation" of some sort. So a form of IPC is just a building block of CORBA. But some people will count those frameworks as IPC, so in that case we might add CORBA, DCOM, RMI (java) etc.. to the lists of ipc mechanisms. (We are very relaxed about that ;-) What are "semaphores"? ====================== You may regard a semaphore as "a flag" (a variable) with a value that indicates the status of a common resource. It is used to let other processes know, that a resource is being used by some process. A process needing the resource, checks the semaphore to determine the resource's status and then decides how to proceed. We have "binary" semaphores, which can only have the values of 0 or 1, or it can be a counter which can be incremented or decremented. So you probably can see that semaphores can be used in synchronising concurrent processes. What is a "mutex"? ================== Quite close to a semaphore, in some development area's, a mutex can be used. It's short for mutual exclusion object. A mutex is a program object that allows multiple program threads to share the same resource, but not simultaneously. When a program is started, a mutex is created with a unique name. After this stage, any thread that needs the resource must lock the mutex from other threads while it is using the resource. The mutex is set to unlock when the data is no longer needed or the routine is finished. Why talking about a mutex at all, if semaphores exists? Indeed they are very similar. A mutex is most often discussed in situations where "critical sections" are also discussed. Especially in the Windows environment, you might come across a mutex and critical sections (but not exclusivly, because for example, you can define them in C as well on Linux). First, it's important to know that a mutex, and a critical section, both can be used as techniques to prevent concurrent access to some resource. A critical section is defined as a segment of code that can be run by at most one thread at any instance of time. All code that accesses a shared resource should be placed within a critical section in order to synchronize access to the resource. In effect, mutually exclusive access to the resource is guaranteed if all accesses are guarded by the same critical section. A mutex object is ‘signaled’ when it is not owned by a thread. A thread takes ownership of the synchronizing mutex object prior to accessing a shared resource. If the resource is already in use by another thread, then access will be blocked. Exclusive access can be guaranteed provided all accesses to the resource are guarded by the same mutex object. Still somewhat vague? Think of a mutex as the lock on a the toilet door. Whoever enters the toilet first, he or she will certainly lock the door (set the mutex). If somebody else comes along and want to use the toilet, that person must simply wait until the first person leaves the toilet. Still can't see the difference to a sempahore? A counting semaphore carries some value "s" that can be incremented or decremented. You can use it if you want to control a certain number of threads in, say, a jobqueue. If "s" is at a certain value, some threads are blocked. The value of "s" corresponds to the number of units of the resource which are free. If "s" increments, some threads jump in for work, and s will be decremented. But a binary semaphore, really "looks a lot" to a mutex.