Вы находитесь на странице: 1из 24


BATCH 12 :
1) SURIYA (11L157) 2) SWETHA (11L158) 3) VANAJA (11L159) 4) VIDHYA SHANKAR (11L160) 5) VINODHINI (11L161)


Inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. Co-operating processes/dependent processes require an IPC mechanism that will allow them to exchange data and information


Information sharing Computational speed-up Modularity Convenience

There are two basic methods of IPC 1) Shared memory : Processes can exchange by reading information by reading and writing on to the shared memory 2) Message sharing : Communication takes place by means of messages exchanged between the cooperating processes


Solaris is a Unix operating system originally developed by Sun Microsystems. It superseded their earlier SunOS in 1993. Oracle Solaris, as it is now known, has been owned by Oracle Corporation since Oracle's acquisition of Sun in January 2010

Solaris was historically developed as proprietary software (closed source) Subsequently, in June 2005, Sun Microsystems founded the OpenSolaris project. With OpenSolaris, Sun wanted to build a developer and user community around the software. After the acquisition of Sun Microsystems in January 2010, Oracle decided to discontinue the OpenSolaris

Solaris is tightly coupled with SPARC scalable processor architecture, which is a RISC instruction set architecture developed by Sun Microsystems The RISC architecture paves way for high performance of the solaris systems Solaris is essentially targetted for Workstations and Servers Solaris is programmed fundamentally in C

Solaris has been tightly coupled with the Sun's hardware - Sparc. Sparc is a RISC based architecture which simply means increased performance for the end user. Mainly because it is optimised to work with the SPARC, it gives better perfromance than the other alternatives available

1. Incompatibility : It is not recommended to run Solaris on other architectures such as Intel, AMD. It is possible to install Solaris on Intel however, the performance would degrade considerably since Solaris cannot make use of Intel that efficiently. 2. Lack of good GUI : Solaris does not have good GUI when compared to the other operating systems 3. Costlier : With other cheaper alternatives such as Linux available, it is costlier to acquire a license of Solaris. Since it is intended to be used on SPARC so the end user often ends up in buying the hardware as well.


Shared memory provides an extremely efficient means of sharing data between multiple processes on a Solaris system, since the data need not actually be moved from one processs address space to another. It refers to the sharing of the same physical memory (RAM) pages by multiple processes Shared memory provides the fastest way for processes to pass large amounts of data to one another.

Intimate Shared Memory (ISM)

It is an optimization introduced first in Solaris 2.2. It allows for the sharing of the translation tables involved in the virtual-to-physical address translation for shared memory pages, as opposed to just sharing the actual physical memory pages. Non-ISM systems maintain a per-process mapping for the shared memory pages. With many processes attaching to shared memory, the non-ISM scheme creates a lot of redundant mappings to the same physical pages that the kernel must maintain.

A 2GB shared segment for 400 processes requires about 800 MB of kernel space to store the address mapping for each process With ISM, the mappings are shared, so we only need the 2 Mbytes of kernel space, regardless of how many processes we attach This kind of shared memory is automatically locked by kernel upon segment creation. The locking prevents paging out , saving significant CPU time.

Semaphores are a shareable resource that takes on a nonnegative integer value. They are manipulted by the P (wait) and V (signal) functions, which decrement and increment the semaphore, respectively. When a process needs a resource, a "wait" is issued and the semaphore is decremented. When the semaphore contains a value of zero, the resources are not available and the calling process spins or blocks (as appropriate) until resources are available. When a process releases a resource controlled by a semaphore, it increments the semaphore and the waiting processes are notified.

Semaphores provide a method of synchronizing access to a sharable resource by multiple processes. The semaphore value is initialized to the number of shared resources. Each time a process needs a resource, the semaphore value is decremented. When the process is done with the resource, the semaphore value is incremented. A zero semaphore value conveys that no resources are currently available The semaphore implementation in Solaris (System V semaphores) allows for semaphore sets, meaning that a unique semaphore identifier can contain multiple semaphores. This approach makes dealing with semaphore makes programming a little easier.

Message queues provide a means to send and receive messages of various size in an asynchronous fashion. Once the message queue has been established, the sender simply constructs the message, assigns a message type, and calls msgsnd(2) function. The system will place the message on the appropriate message queue until a msgrcv(2) is successfully executed. Sent messages are placed at the back of the queue, and messages are received from the front of the queue; thus the queue is implemented as a FIFO (First In, First Out).

The message queue facility implements a message type field, which is user defined. So, programmers have some flexibility, since the kernel has no predefined knowledge of different message types. The number of resources that the kernel allocates for message queues is tun-able. Values for various message queue tunable parameters can be increased from their default value , so more resources are made available for systems running applications that make heavy use of message queues.

A door is a "file" descriptor used to describe a procedure in a process and optionally some additional state associated with the procedure. It is similar to an object in C++ Doors are created by server processes and called by client processes. Unlike most Remote procedure call systems, each door has only one server procedure. A door server contains a thread that sleeps, waiting for an invocation from the door client. A client makes a call to the server through the door, along with a small (16 Kbyte) payload. When the call is made from a door client to a door server, scheduling control is passed directly to the thread in the door server. Once a door server has finished handling the request, it passes control and response back tothe calling thread.

The doors system provides a way for clients and servers to get information about each other. For example, a server can check the client's user credentials or process ID to decide whether the client is allowed to do something. Doors can be used to synchronize access to shared memory segments, allowing singlecopy data transfer. Doors are a low-latency method of invoking a procedure in local process.

A process can become a door by using the door_create(3X). This function returns a door descriptor which is used by the client to reference a particular door. Other processes can then invoke the procedure by issuing a door_call(3X),specifying the correct door descriptor.