OPERATING SYSTEMS

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

INTER-PROCESS COMMUNICATION IN SOLARIS

WHAT IS IPC?

• 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

REASONS FOR THE NEED OF IPC

• Information sharing• Computational speed-up• Modularity• Convenience

METHODS OF IPC

There are two basic methods of IPC1) 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 co-operating processes

SOLARIS

• 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

Advantages

• 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

Disadvantages

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.

METHODS OF IPC IN SOLARIS

SHARED MEMORY

• 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 process’s 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

• Semaphores are a shareable resource that takes on a non-negative 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

• 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.

SOLARIS DOORS• 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 .

USES OF DOORS

• 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 single-copy data transfer.

• Doors are a low-latency method of invoking a procedure in local process.

Implementation

• 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.

THANK YOU