POSIX 1003.1B

POSIX 1003.1B Asynchronous Input/Output

Asynchronous Input/Output allows a process (thread) to start multiple simultaneous read and/or write operations to multiple files, wait for or obtain notification of completion of requested operations, and to retrieve the status of completed operations. The purpose of the POSIX Asynchronous I/O facility is to allow a process (thread) to overlap some elements of computation and information processing with I/O processing. The POSIX Asynchronous I/O facility includes the following interface functions:

Summary of Change

This is a new functionality that is being introduced in 11.0.

The following is the list of manpages for the POSIX Asynchronous I/O system-calls:

aio(5) aio_fsync(2) aio_suspend(2) aio_cancel(2) aio_read(2) aio_write(2) aio_error(2) aio_return(2) lio_listio(2)

POSIX 1003.1B Message Passing

This new interprocess communication mechanism provides a message passing facility as defined by the POSIX 1003.1B Standard. Although it is not intended to replace the existing System-V message passing sub-system, the new mechanism is specifically designed to meet the requirements of real-time processes. Its `send' and `receive' operations are optimized for high performance. It also includes a notification mechanism based on real-time signals.

Eight new system-calls have been introduced to support this interface. The new calls are: mq_open, mq_close, mq_unlink, mq_notify, mq_send, mq_receive, mq_setattr and mq_getattr.

Summary of Change

This is a new functionality that is being introduced in 11.0.

The following is the list of manpages for the POSIX Message Passing system-calls:

mq_close(2) mq_notify(2) mq_receive(2) mq_setattr(2) mq_getattr(2) mq_open(2) mq_send(2) mq_unlink(2)

POSIX 1003.1B Shared Memory Objects

A "shared memory object" is a memory object (like a file), that can be concurrently mapped into the address space of one or more processes. The mmap() and munmap() functions allow a process to manipulate its address space by mapping such memory objects into it and removing them from it. When multiple processes map the same memory object, they can share access to the underlying data.

Shared memory objects have been introduced in the POSIX 1003.1B Real Time Extension Specification. This will allow systems (eg. embedded systems) which don't implement a full file system, to still be able to use memory objects which can be mapped into the address space of processes. In our implementation, we use the underlying file system, to implement shared memory objects. Two new system-calls have been added to supported shared memory objects. They are:

The shm_open() system-call, establishes a connection between a shared memory object and a file descriptor. This file descriptor is then used for other operations on the shared memory objects (such as mmap(), close(), etc.). The file descriptors returned by shm_open(), don't remain open across exec*() calls.

The shm_unlink() system-call, removes the name of the specified shared memory object. The object itself is not destroyed, until all open and mapped references to it have been closed.

Summary of Changes

This is a new functionality that is being introduced in 11.0.

The following is the list of man-pages for the POSIX Shared Memory Objects system-calls:

shm_open(2) shm_unlink(2)

POSIX 1003.1B Memory Locking

This new memory locking mechanism provides per-page memory locking and unlocking facilities as defined by the POSIX 1003.1B Standard. POSIX defines several new functions to enable users to lock/unlock pages in memory. A privileged user wishing to lock a section of memory must invoke the mlock() or mlockall() system call. The mlock() routine, given an address and length, will ensure that all the user pages which encompass this address range are made memory resident and locked. The mlockall() system call locks all of the user's memory. Unlocking memory can be accomplished with an equivalent pair of functions - munlock() and munlockall(). The munlock() routine, given an address and length, unlocks all the user pages in the address range. The munlockall() system call unlocks all of the user's memory. Although HP-UX has long supported the plock() interface, which does a similar function, there is a fundamental difference - plock() only supports locking at the segment level. The POSIX memory locking routines, on the other hand, support locking at the page level. A single page can be locked or unlocked.

Summary of Change

This is a new functionality that is being introduced in 11.0.

The following is the list of manpages for the POSIX Memory Locking system calls:

mlock(2) mlockall(2) munlock(2) munlockall(2)