|
|
|
|
|
|
|
|
MPE/iX Developer's Kit Reference Manual Volume 2: HP 3000 MPE/iX Computer Systems > Chapter 2 SVID IPC Library Function Descriptions
Overview of SVID IPC |
|
Developing an application consisting of several processes usually requires some form of information exchange and resource synchronization. Many applications developed for use on UNIX®-based computer systems use the IPC services defined by the AT&T System V Interface Definition (SVID2). The MPE/iX SVID IPC library is provided (along with the POSIX.1/iX library) to enable application developers to substantially reduce the costs associated with successfully porting a UNIX-based application to a Series 900 HP 3000 computer system. The SVID IPC library provides three facilities and an access control feature:
For each of the three SVID IPC facilities there are C/iX library functions available for allocation, deallocation, and control of the facilities. Use an xxxget() function to either create a resource of the desired type (for example, a shared memory area) or obtain an identifier for an existing resource. Use an xxxctl() function to perform a variety of control operations on an IPC resource. Common control operations include returning usage statistics about a resource and modifying attributes of the resource. Additional functions are provided in each facility to perform activities unique to the facility. For example, the message queue facility provides functions to write to and read from a specified message queue. Message queues are one form of process-to-process communication. Data sent from a process to a message queue is copied into a data buffer which is then linked into the list of data buffers for that queue. Processes can read and write to message queues in any arbitrary order. For example, a process can send a message to a queue even if no other process is currently waiting to read a message from the same queue. Following are the functions available to manage SVID IPC message queues:
The shared memory facility allows processes to communicate via a common memory area mapped to the address space of each process sharing the memory. When a process modifies the contents of a shared memory area, the data is immediately available to other processes. The most common usage of this facility is to allocate application global data needed by all processes sharing the memory area. An example of shared memory access is when one process writes data to a shared memory area and a second process reads the data from the same shared memory area. In this case, there is no overhead involved in copying the data from process A to process B. Process B has immediate access to the data through the shared memory area. Following are the functions available to manage SVID IPC shared memory.
The semaphore facility allows processes to synchronize operations when sharing a common resource. An example of semaphore facility use is when two or more processes synchronize access to a commonly shared memory area. In this case, a process performing a write operation to a shared memory area can suspend itself until other processes have completed read operations on the same shared memory area. Following are the functions available to manage SVID IPC semaphores:
Access control is provided through a key value, known to the application using SVID IPC functions, that is associated with each resource being shared by multiple processes. This key is used by different processes who have agreed to manage access to the resource using the shared key. All SVID IPC facilities require the user to supply a key to be used by the msgget(), semget(), and shmget() functions to obtain identifiers. The ftok() function provides a user with a key value that can be used by processes sharing the same resource. The key value returned by ftok() is based upon a file name to which the application has access. There are many other ways to form keys, but it is necessary for each system to define standards for forming them. If a standard is not adhered to, it is possible for unrelated processes to unintentionally interfere with each other's operation. Therefore, it is strongly suggested that the id parameter of ftok(), if used for key generation, should in some sense refer to a project so that keys do not conflict across a given system.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||
|
|||||||||
