Windows & Unix IPC Introduction (Part.3)

4. Shared Memory

Shared memory allows multiple processes to share virtual memory space so changes made by one process are instantly reflected in other processes. This affords the fastest possible IPC but is not necessarily the easiest to coordinate between the two processes. Shared memory is unique in that it allows random access of data, whereas most other IPC mechanisms mandate sequential access to data. Typically, one process creates a shared segment, and needs to set access permissions for the

segment. It is then mapped into the process’s address space after the process attaches to it. Usually the creating process initializes the memory, but after this other processes that have been given access permission to the segment can use it freely. When another process does use it, it is mapped into its address space. Oftentimes semaphores are used by the original process to be sure that only one other process is allowed to access the memory at any one time, although a readers/writers lock

may be a more suitable solution. When no process needs the memory segment anymore, the creating process can delete it.

 

4.1 Creating a Shared Memory Segment

When programming for UNIX, a new shared memory segment can be created using the shmget()       call. Using shmget() also generates the required data structures. If a shared memory segment was created by another process previously, using shmget() allows a process to gain access to the existing segment since shared memory segments are identified by unique identifiers returned by the call. When creating a new segment, the programmer can specify a key to associate with an existing shared memory segment, the size of the segment requested, and the creation and access conditions. Note that creating a shared segment only reserves space for it; the process still cannot access it.

 

Using a shared memory region under Windows NT requires two distinct steps, much as it does in UNIX: creating a kernel object specifying the size of the shared area and then mapping this filemapping object into the process’s address space.

 

To carry out the first step the CreateFileMapping() call is used. This call usually allows a file to be accessed as if in memory (not unlike the UNIX mmap() call) but can be used to create a place in one of the system paging files. This place, once reserved, can be accessed by name via the kernel. When using CreateFileMapping in this way, the file handle passed in is a special constant representing that a paging file should be used. Other parameters that CreateFileMapping() takes include flags for security attributes, access specifiers (which are normally set to allow page read and write access when using shared memory), the size of the segment to be mapped, and name that the segment can be referred to as. If the call returns successfully, a handle to a file-mapping kernel object is available to the calling process. It is not necessary to use the paging file for the mapping; however, doing so prevents processes from needing to agree on using a common file name and eliminates the possibility of having temporary files to cleanup. The choice of whether or not to use a pagefile or some other file effectively allows Windows NT to mimic both types of mapping possible under UNIX.3 However, UNIX simplifies the case of general (not file mapped) shared memory by completely removing the burden of dealing with files. (Windows NT requires the decision to be made earlier in the process, however; the second type of

mapping has not yet been presented.)

 

4.2 Controlling a Shared Memory Segment

Once a UNIX process has created a shared memory segment, it can control it using the shmctl() system call. This call can potentially affect existing shared memory segments as well as the system-maitained shared memory control structures. The call takes a key representing a previously created segment, a command (specified via a constant), and a buffer containing a struct that effectively serves as the parameters for the specified command. Possible commands include:

ü  IPC_STAT: returns the values of the associated data structure to a process having read access to the segment

ü  IPC_SET: allows a process with an effective UID of superuser or the UID of the process used to create the segment to modify the segment’s associated user and group identifiers, as well as change the access permissions

ü  IPC_RMID: remove the system data structure, effectively indicating that the process is done with the shared segment and that if no other process is still using it then it can be deleted

ü  SHM_LOCK: allows the superuser to lock a shared segment in memory

ü  SHM_UNLOCK: allows the superuser to unlock a shared segment locked into memory Windows NT does not offer similar features to user-level processes. This higher degree of management by the kernel is useful at times but does place some limits on the flexibility of shared memory for Windows NT.

 

4.3 Shared Memory Operations

UNIX features two operations to work with shared memory: shmat() and shmdt(). These allow processes to attach and detach from shared memory segments, respectively.

 

When a process attached to a shared memory segment using shmat(), the referenced shared memory is mapped into the calling process’s data segment. The call takes an identifier of an existing shared memory segment, a flag that specifies the access permissions for the shared segment and to request special conditions (such as address alignment), and a suggestion for placement of the segment. This last argument is passed in as a void*, which is usually set to null, indicating that the system should choose the addresses that it feels best. However, the process

could pass in a suggested address. The memory is then mapped into the nearest available page address.

 

When a process wishes to detach from a segment, it can use the shmdt() system call. The call takes only a reference to an attached memory segment. When programming for UNIX, programmers can use the mmap() system call to map a file into a process’s virtual address space. Mapping files has several advantages over using traditional shared memory segments. In particular, standard system calls can be used to manipulate the memory as desired (instead of the specialized calls that shared memory segments require) and files are persistent. The mmap() call takes several parameters. It accepts a user-specified address to try to

map the file into, much as the shmat() call does. In addition, the length of the mapped memory area can be specified along with the access privileges that should apply. Various flags can be used to set attributes for the mapping, such as whether the map should be shared or private, whether the address needs to be fixed, and whether or not swap space should be reserved for the mapping. Although the file will be unmapped when the process terminates, the process can unmap it at any time using munmap(), which accepts the address and size of the memory block as parameters.

 

Windows NT provides equivalent functionality through the use of the OpenFileMapping() and UnmapViewOfFile() system calls.

 

The OpenFileMapping() call returns a handle to a file-mapping kernel object that was previously created using CreateFileMapping(). As parameters it takes the level of access that is desired for the segment, whether or not child processes should inherit the handle, and the name of the memory region to open (as specified when CreateFileMapping() was called). After the handle to the kernel object is acquired, a pointer to the memory that it represents is required. The MapViewOfFile()

call can be used to get this pointer. MapViewOfFile() takes the handle returned by

CreateFileMapping(), the desired level of access to the memory, and the size of the region to map as parameters. It returns a pointer to the beginning of the memory segment.

 

When the shared map is no longer required, it should be released using UnmapViewOfFile(). It takes the address of the memory (as returned by MapViewOfFile()) as a parameter. The programmer should also be careful to close the handle to the file-mapping kernel object.

 

5. Mailslots

Mailslots, available only in Windows NT, provide one-way communication between processes. A mailslot is a pseudofile; it resides in memory, and standard file functions are used to access it. The data in a mailslot message can be in any form. When all handles to a mailslot are closed, the mailslot and all the data it contains are deleted, so mailslots cannot be used for long-term storage.

 

A mailslot server is a process that creates and owns a mailslot. When the server creates a mailslot, it receives a mailslot handle. This handle must be used when a process reads messages from the mailslot. Only the process that creates a mailslot or obtains a handle to can read from the mailslot. All mailslots are local to the process that creates them; a process cannot create a remote mailslot. A mailslot client is a process that writes a message to a mailslot. Any process that has the name of a mailslot can put a message there. New messages follow any existing messages in the mailslot.

 

Processes that create mailslots act as servers to other processes that send messages to it by writing a message to its mailslot. Incoming messages are always appended to the mailslot and are saved until the mailslot server has read them. A process can be both a mailslot server and a mailslot client, so two-way communication is possible using multiple mailslots. This is useful for implementing a simple message-passing facility within a domain.

 

Mailslot clients can send a message to any number of mailslot servers located anywhere on the network with a single call, as long as the mailslots all share the same name. The message can also be restricted to the local machine or a specific machine on the network. Messages broadcast to all mailslots on a domain can be no longer than 400 bytes, whereas messages sent to a single mailslot are limited only by the maximum message size specified by the mailslot server when it created the mailslot.

 

6. Conclusions

6.1 Review

Both UNIX and Windows NT provide efficient pipe implementations that are excellent in their own unique ways. The UNIX implementation is very simple to use whereas the Windows NT implementation is quite complex (in comparison), but affords the programmer substantially more flexibility. The abundance of information available at runtime allows powerful servers handling multiple clients to be created. The possibility for pipes to alternate between being synchronous and asynchronous is also a nice feature. Windows NT also natively supports multiple pipes, does not restrict the use of unnamed pipes to related processes, and allows bi-directional communication

using a single pipe. Under both operating systems, pipes provide a reliable means for IPC, and the two parties can verify receipt of data in real-time.

 

Windows sockets, embodied by the WinSock v2.2 API, offer a good programming interface for peer-to-peer communications. The WinSock API is high-level and easy to program to, and it highly optimized for the Windows NT platform. It offers the highest data transfer rate of any peerto-peer mechanism, especially when used with overlapped I/O. Providing protocol independence as well as protocol transparency when used with the Service Registration API, it is superior to standard Berkeley sockets. If offers all of the functionality of the Berkeley socket package, usually in the same way; porting code from Berkeley sockets to Windows sockets is trivial with a couple

of minor exceptions. In addition to natively supporting protocols not offered by Berkeley sockets, Windows sockets bring a host of performance and ease of use advantages to the programmer, including the Service Registration API, overlapped I/O, the choice of synchronous or asynchronous I/O, quality of service support, and completion ports.

 

Both UNIX and Windows NT offer suitable mechanisms for creating shared memory segments. For the case of general shared memory, UNIX is easier to work with since the programmer need not worry about file mappings and the sequence of system calls o be used is somewhat more straightforward. UNIX claims an even larger advantage when mapping files into memory. UNIX requires only one mmap() call to complete the entire mapping operation whereas Windows NT requires a sequence of calls. Windows NT also mandates that the programmer cleanup after all shared memory operations, but UNIX handles this for the programmer when reference counts drop to zero or processes terminate.

 

Mailslots are a Windows NT-specific IPC mechanism that allows clients to send messages to repositories on its local computer, on another computer, or to all repositories with the same name on all computers on a given network segment. They serve as a standardized mechanism for sending a broadcast-style message. Mailslot messages are sent using datagrams for network efficiency, meaning that receipt of a message is not guaranteed. The closest approximation to a mailslot in UNIX is a named pipe.

 

6.2 Selecting an IPC Mechanism for Windows NT

Each of the IPC mechanisms discussed has its advantages and disadvantages; each is the optimal solution for a particular problem.

ü  Anonymous pipes provide an efficient way to redirect standard input or output to child processes on the same computer. Named pipes provide a simple programming interface for transferring data between two processes, whether they reside on the same computer or over a network.

ü  Windows Sockets are a protocol-independent interface capable of supporting current and emerging networking capabilities, such as quality of service monitoring, robust asynchronous communication, I/O completion ports for superior performance, and protocol-specific network features. In most cases, applications currently using files for communication can be easily adapted to use sockets.

ü  Shared memory is an efficient way for two or more processes on the same computer to share data, but the programmer must provide synchronization between the processes.

ü  Mailslots offer an easy way for applications to send and receive short messages. They also provide the ability to broadcast messages across all computers in a network domain. Since datagrams are used, they should not be considered a reliable means of IPC.

 

Choosing which of these technologies is up to the individual application programmer. After accounting for the balance of performance and ease of use desired and the technical requirements of the application, a selection can usually be made easily. In general, however, Windows sockets usually provide the best blend of performance, scalability, and ease of use.