This action might not be possible to undo. Are you sure you want to continue?
It superseded their earlier SunOS in 1992. 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, then in June 2005 Sun Microsystems released most of the code base under the CDDL license, and founded the Open Solaris open source project. With Open Solaris 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 Open Solaris distribution and the development model. As a result, the Open Solaris community forked the Open Indiana project, as part of the Illumes Foundation. However, starting with Solaris 11, updates to the Solaris source code will still be distributed under the CDDL license, after full binary releases are made. Oracle will also begin a technology partner program, called Oracle Technology Network (OTN), to permit their industry partners access to the indevelopment Solaris source code.
What is Inter Process Communication?
Official definition: Inter process communication (IPC) is used for programs to communicate data to each other and to synchronize their activities. Semaphores, shared memory, and internal message queues are common methods of inter process communication. What it means: IPC is a method for two or more separate programs or processes to communicate with each other. Or we can say that Inter-process communication (IPC) is a set of techniques 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. This avoids using real disk-based files and the associated I/O overhead to pass information. Like a file, you must first create or open the resource, use it and close it. Like real files, the resources have an owner, a group, and permissions. Until you remove the resource it continues to exist. Unlike real disk-based files, semaphores, message queues and shared memory do not persist across reboots. The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
Reasons to use Inter Process Communication:
Use IPC’s when you need to talk between programs, you want the talking to be fast, and you do not want to write the code to manage the low-level details of communication between the processes. Since these are kernel routines, the kernel will take care of the details of the communication. For example, when you are waiting for a resource that is protected by a semaphore to become available, if you request access and the resource is currently in use, the kernel will place you in a waiting queue. When the resource becomes available, the kernel unblocks your process and you can continue. The kernel also ensures that operations are atomic, which means that a test and increment operation to set a semaphore cannot be interrupted. 1
There are several main reasons for providing an environment that allows process cooperation: Information sharing Speedup; Modularity; Convenience; and Privilege separation.
IPC’s in solaris (os):Interprocess communication (IPC) encompasses facilities provided by the operating system to enable the sharing of data (shared memory segments), the exchange of information and data (message queues), and synchronization of access to shared resources (semaphores) between processes and threads on the same system. Contrast IPC to networking-based facilities, such as sockets and RPC interfaces, which enable communication over a network link between distributed systems. Early IPC facilities originated in AT&T Unix System V, which added support for shared memory, semaphores, and message queues around 1983. This original set of three IPC facilities is generally known as System V IPC. Over time, a similar set of IPC features evolved from the POSIX standards, and we now have POSIX semaphores, shared memory, and message queues. The System V and POSIX IPCs use different APIs and are implemented differently in the kernel, although for applications they provide similar functionality. Other facilities for interprocess communication include memory mapped files, named pipes (also known as FIFOs), Unix domain sockets, and recently added Solaris Doors, which provides an RPC-like facility for threads running on the same system. Each method by which an application can do interprocess communication offers specific features and functionality which may or may not be useful for a given application. It’s up to the application developer to determine what the requirements are and which facility best meets those requirements. Doors are a low-latency method of invoking a procedure in local process. 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 to the calling thread. The scheduling control allows ultra-low-latency turnaround because the client does not need to wait for the server thread to be scheduled to complete the request.
Release Notes Sun UNIX 0.7 • First version of Sun’s UNIX, based on 4.BSD from UniSoft. • Bundled with the Sun-1, Sun’s first workstation based on the Motorola 68000 processor; SunWindows GUI. SunOS 1.0 SunOS 2.0 • Sun-2 workstation, 68010 based. • Virtual file system (VFS) and vnode framework allows multiple concurrent file system types. • NFS implemented with the VFS/vnode framework. • New virtual memory system integrates the file system cache with the memory system. • Dynamic linking added. • The first SPARC-based Sun workstation, the Sun-4. Support for the Intel-based Sun 386i. • Supports the SPARCstation 1+, IPC, SLC. • OpenWindows graphics environment • Asymmetric multiprocessing (ASMP) for sun4m systems (SPARCstation-10 and -600 series MP (multiprocessor) servers). • Solaris 2.x is born, based on a port of System V Release 4.0. • VFS/vnode, VM system, intimate shared memory brought forward from SunOS. • Uniprocessor only. • First release of Solaris 2, version 2.0, is a desktop-only developers release.
SunOS 4.1 SunOS 4.1.3
Solaris 2.1 Solaris 2.2
• Four-way symmetric multiprocessing (SMP). • Large (> 2 Gbyte) file system support. • SPARCserver 1000 and SPARCcenter 2000 (sun4d architecture).
Solaris 2.1-x86 • Solaris ported to the Intel i386 architecture.
• 8-way SMP. • Device power management and system suspend/resume functionality added. • New directory name lookup cache. • 20-way SMP. • New kernel memory allocator (slab allocator) replaces SVR4 buddy allocator. • Caching file system (cachefs). • Large-page support for kernel and System V shared memory. • Fast local interprocess communication (Doors) added. • NFS Version 3. • Supports sun4u (UltraSPARC) architecture. Ultra SPARC-I-based products introduced— the Ultra-1 workstation. • First release supporting multiprocessor UltraSPARC-based systems. • 64-way SMP. • Ultra-Enterprise 3000–6000 servers introduced. • Added support for large (> 2 Gbyte files). • Dynamic processor sets. • Kernel-based TCP sockets. • Locking statistics. • UFS direct I/O. • 64-bit kernel and process address space. • Logging UFS integrated. • Priority Paging memory algorithm.
System V 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. As the name implies, shared memory is exactly that: the sharing of the same physical memory (RAM) pages by multiple processes, such that each process has mappings to the same physical pages and can access the memory through pointer dereferencing in code. Shared memory provides the fastest way for processes to pass large amounts of data to one another. As the name implies, shared memory refers to physical pages of memory that are shared by more than one process.
Of particular interest is the "Intimate Shared Memory" facility, where the translation tables are shared as well as the memory. This enhances the effectiveness of the TLB (Translation Lookaside Buffer), which is a CPU-based cache of translation table information. Since the same information is used for several processes, available buffer space can be used much more efficiently. In addition, ISM-designated memory cannot be paged out, which can be used to keep frequently-used data and binaries in memory. Database applications are the heaviest users of shared memory. Vendor recommendations should be consulted when tuning the shared memory parameters.
Intimate Shared Memory (ISM)
Intimate shared memory (ISM) 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. Typically, nonISM_systems maintain a per-process map-ping for the shared memory pages. With many processes attaching to shared memory, this scheme creates a lot of redundant mappings to the same physical pages that the kernel must maintain. Additionally, all modern processors implement some form of a Translation Look aside Buffer (TLB), which is (essentially) a hardware cache of address translation information. SPARC processors are no exception, and the TLB, just like an instruction and data cache, has limits as to how many translations it can maintain at any one time. As processes are context-switched in and out, we can reduce the effectiveness of the TLB. If those processes are sharing memory and we can share the memory mappings also, we can make more effective use of the hardware TLB. Let’s consider just one simple example. A database system uses shared memory for caching various database objects, such as data, stored procedures, indexes, etc. All commercial database products implement a caching mechanism that uses shared memory. Assume a large, 2-Gbyte shared segment is configured and there are 400 database processes, each attaching to the shared segment. Two gigabytes of RAM equates to 262,144 eight-kilobyte pages. Assuming that the kernel needs to maintain 8 bytes of information for each page mapping (two 4-byte pointers), that’s about 2 Mbytes of kernel space needed to hold the translation information for one process. Without ISM, those mappings are replicated for each process, so multiply the number times 400, and we now 5
need 800 Mbytes of kernel space just for those mappings. With ISM, the mappings are shared, so we only need the 2 Mbytes of space, regardless of how many processes attach. In addition to the translation table sharing, ISM provides another useful feature: when ISM is used, the shared pages are locked down in memory and will never be paged out. In Solaris releases up to and including Solaris 7, there is not an easy way to tell whether or not a shared segment is an ISM shared segment. It can be done but requires root permission and use of the crash(1M) utility.
System V Semaphores
A semaphore, as defined in the dictionary, is a mechanical signaling device or a means of doing visual signaling. The analogy typically used is the railroad mechanism of signaling trains, where mechanical arms would swing down to block a train from a section of track that another train was currently using. When the track was free, the arm would swing up, and the waiting train could then proceed. 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. The notion focusing semaphores as a means of synchronization in computer soft-ware was originated by a Dutch mathematician, E. W. Dijkstra, in 1965. Dijkstra’s original work defined two semaphore operations, wait and signal. The operations were referred to as P and V operations. The P operation was the wait, which decremented the value of the semaphore if it was greater than zero, and the V operation was the signal, which incremented the semaphore value. The terms P and V originate from the Dutch terms for try and increase. P is from Probeer, which means try or attempt, and V is from Verhoog, which means increase. Semaphores provide a method of synchronizing access to a sharable resource by multiple processes. They can be used as a binary lock for exclusive access or as a counter; they manage access to a finite number of shared resources, where 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 to the calling process that no resources are currently available, and the calling process blocks until another process finishes using the resource and frees it. The semaphore implementation in Solaris (System V semaphores) allows for semaphore sets, meaning that a unique semaphore identifier can contain multiple semaphores. The semaphore system calls allow for some operations on the semaphore set. This approach makes dealing with semaphore sets programmatically a little easier. Just as with shared
memory, the system checks for the maximum amount of available kernel memory and divides that number by 4, to prevent semaphore requirements from taking more than 25 percent of available kernel memory. A kernel mutex lock is created for each semaphore set. This practice results in fairly fine grained parallelism on multiprocessor hardware, since it means that multiple processes can do operations on different semaphore sets concurrently. For operations on semaphores in the same set, the kernel needs to ensure atomicity for the application. Atomicity guarantees that a semaphore operation initiated by a process will complete without interference from another process, whether the operation is on a single semaphore or multiple semaphores in the same set.
System V Message Queues
Message queues provide a means for processes to send and receive messages of various size in an asynchronous fashion on a Solaris system. As with the other IPC facilities, the initial call when message queues are used is an ipcget call, in this case, msgget(2). The msgget(2) system call takes a key value and some flags as arguments and returns an identifier for the message queue. Once the message queue has been established, it’s simply a matter of sending and receiving messages. Applications use msgsnd(2) and msgrcv(2) for those purposes. The sender simply constructs the message, assigns a message type, and calls msgsnd(2). 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 (programmer) defined. So, programmers have some flexibility, since the kernel has no embedded or predefined knowledge of different message types. Programmers typically use the type field for priority messaging or directing a message to a particular recipient Solaris 2.5.1 and before used very coarse-grained mutex locking for message queues, which resulted in uneccessary contention as compared to 2.6 and later versions. Kernel Resources for Message Queues 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 values so more resources are made available for systems running applications that make heavy use of message queues. A final note on kernel locking. All versions of the Solaris, up to and including Solaris 2.5.1, do very coarse grained locking in the kernel message queue module. Specifically, one kernel mutex is initialized to protect the message queue kernel code and data. As a result, applications running on multiprocessor platforms using message queues do not scale well. This situation is 7
changed in Solaris 2.6, which implements a finer-grained locking mechanism, allowing for greater concurrency. The improved message queue kernel module has been backported and is available as a patch for Solaris 2.5 and 2.5.1.
POSIX IPC:The evolution of the POSIX standard and associated application programming interfaces (APIs) resulted in a set of industry-standard interfaces. The POSIX IPC facilities are similar in functionality to System V IPC but are abstracted on top of memory mapped files. The POSIX library routines are called by a program to create a new semaphore, shared memory segment, or message queue using the Solaris file I/O system calls. Internally in the POSIX library, the IPC objects exist as files. The object type exported to the program through the POSIX interfaces is handled within the library routines. The POSIX implementation of all three IPC facilities is built on the notion of POSIX IPC names, which essentially look like file names but need not be actual files in a file system. This POSIX name convention provides the necessary abstraction, a file descriptor, to use the Solaris file memory mapping interface, on which all the POSIX IPC mechanisms are built. This is very different from the System V IPC functions, where a key value was required to fetch the proper identifier of the desired IPC resource. In System V IPC, a common method used for generating key values was the ftok(3C) (file-to-key) function, where a key value was generated based on the path name of a file. POSIX eliminates the use of the key, and processes acquire the desired resource by using a file-name convention. They are quite similar in form and function to their System V equivalents but very different in implementation.
Solaris Doors:Doors provide a facility for processes to issue procedure calls to functions in other processes running on the same system. Using the APIs, a process can become a door server, exporting a function through a door it creates by using the door_create(3X) interface. Other processes can then invoke the procedure by issuing a door_call(3X), specifying the correct door descriptor. The door APIs were available in Solaris 2.5.1 but not documented and, at that point, subject to change. Solaris 2.6 was the first Solaris release that included a relatively stable set of interfaces (stable in the sense that they were less likely to change). The Solaris kernel ships with a shared object library, libdoor. so, that must be linked to applications using the doors APIs. Table 10-10 describes the door APIs available in Solaris 2.6 and Solaris 7. During the course of our coverage of doors, we refer to the interfaces as necessary for clarity.
Security Features:The Trusted Solaris environment supports the System V inter-process communication (IPC) mechanism and provides security features for labeled communications between System V IPC objects and both privileged and unprivileged processes.
• • • •
"Privileged Operations" "Data Types, Header Files, and Libraries " "Programming Interface Declarations" "Using Shared Memory Labels"
Privileged Operations: System V IPC objects are subject to discretionary and mandatory access controls, and discretionary ownership controls. A System V IPC object is created from a key and accessed by an object descriptor returned when the IPC object is created. The object descriptor, like a file descriptor, is used for future operations on the object. The sensitivity label of the System V IPC object is the same as the sensitivity label of its creating process unless the creating process has the privilege to create the System V IPC object at a different label. A process can access a System V IPC object at its same sensitivity label unless the process has the privilege to access a System V IPC object at another label. Because keys are qualified by the sensitivity label at which they are created, there can be many objects that use the same key, but no more than one instance of a key (object ID) at a given sensitivity label.
• • •
Message queues allow processes to place messages into a queue where any process can retrieve the message. Semaphore sets synchronize processes and are often used to control concurrent access to shared memory regions. Shared memory regions allow multiple processes to attach to the same region of memory to access changes to the memory.
Discretionary Access and Ownership Controls: Discretionary access to a System V IPC object is granted or denied according to the read and write modes associated with the object for owner, group, and other in much the same way as file access. System V IPC objects also has the creator user and creator group sets that control attribute change requests. The process that creates a System V IPC object is the owner and can set the discretionary permission bits to any value. To override discretionary access and ownership restrictions, the process needs the ipc_dac_read, ipc_dac_write, or ipc_owner privilege in its effective set, depending on the interface used or operation requested.
Mandatory Access Controls: Unprivileged processes can only refer to System V IPC objects and return an IPC descriptor at the process's correct sensitivity label. This makes the mandatory access controls read-equal and write-equal and eliminates naming and access conflicts when an unmodified base Solaris application using System V IPC runs at multiple sensitivity labels. To override mandatory access restrictions, the process needs the ipc_mac_read or ipc_mac_write privilege in its effective set, depending on the interface used.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.