JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Programming Interfaces Guide     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


1.  Memory and CPU Management

2.  Remote Shared Memory API for Solaris Clusters

3.  Session Description Protocol API

4.  Process Scheduler

5.  Locality Group APIs

6.  Input/Output Interfaces

7.  Interprocess Communication

8.  Socket Interfaces

9.  Programming With XTI and TLI

10.  Packet Filtering Hooks

11.  Transport Selection and Name-to-Address Mapping

12.  Real-time Programming and Administration

Basic Rules of Real-time Applications

Factors that Degrade Response Time

Synchronous I/O Calls

Interrupt Servicing

Shared Libraries

Priority Inversion

Sticky Locks

Runaway Real-time Processes

Asynchronous I/O Behavior

Real-time Files

The Real-Time Scheduler

Dispatch Latency

Scheduling Classes

Dispatch Queue

Dispatching Processes

Process Preemption

Kernel Priority Inversion

User Priority Inversion

Interface Calls That Control Scheduling

Using priocntl

Other interface calls

Utilities That Control Scheduling



Configuring Scheduling

Dispatcher Parameter Table

Reconfiguring config_rt_dptbl

Memory Locking

Locking a Page

Unlocking a Page

Locking All Pages

Recovering Sticky Locks

High Performance I/O

POSIX Asynchronous I/O

Solaris Asynchronous I/O

Notification (SIGIO)

Using aioread

Using aiowrite

Using aiocancel

Using aiowait

Using poll()

Using the poll Driver

Using close

Synchronized I/O

Synchronization Modes

Synchronizing a File

Interprocess Communication

Processing Signals

Pipes, Named Pipes, and Message Queues

Using Semaphores

Shared Memory

Asynchronous Network Communication

Modes of Networking

Timing Facilities

Timestamp Interfaces

Interval Timer Interfaces

13.  The Solaris ABI and ABI Tools

A.  UNIX Domain Sockets


Memory Locking

Locking memory is one of the most important issues for real-time applications. In a real-time environment, a process must be able to guarantee continuous memory residence to reduce latency and to prevent paging and swapping.

This section describes the memory locking mechanisms that are available to real-time applications in SunOS.

Under SunOS, the memory residency of a process is determined by its current state, the total available physical memory, the number of active processes, and the processes' demand for memory. This residency is appropriate in a time-share environment. This residency is often unacceptable for a real-time process. In a real-time environment, a process must guarantee a memory residence to reduce the process' memory access and dispatch latency.

Real-time memory locking in SunOS is provided by a set of library routines. These routines allow a process running with superuser privileges to lock specified portions of its virtual address space into physical memory. Pages locked in this manner are exempt from paging until the pages are unlocked or the process exits.

The operating system has a system-wide limit on the number of pages that can be locked at any time. This limit is a tunable parameter whose default value is calculated at boot time. The default value is based on the number of page frames minus another percentage, currently set at ten percent.

Locking a Page

A call to mlock(3C) requests that one segment of memory be locked into the system's physical memory. The pages that make up the specified segment are faulted in. The lock count of each page is incremented. Any page whose lock count value is greater than zero is exempt from paging activity.

A particular page can be locked multiple times by multiple processes through different mappings. If two different processes lock the same page, the page remains locked until both processes remove their locks. However, within a given mapping, page locks do not nest. Multiple calls of locking interfaces on the same address by the same process are removed by a single unlock request.

If the mapping through which a lock has been performed is removed, the memory segment is implicitly unlocked. When a page is deleted through closing or truncating the file, the page is also implicitly unlocked.

Locks are not inherited by a child process after a fork(2) call. If a process that has some memory locked forks a child, the child must perform a memory locking operation on its own behalf to lock its own pages. Otherwise, the child process incurs copy-on-write page faults, which are the usual penalties that are associated with forking a process.

Unlocking a Page

To unlock a page of memory, a process requests the release of a segment of locked virtual pages by a calling munlock(3C). munlock decrements the lock counts of the specified physical pages. After decrementing a page's lock count to 0, the page swaps normally.

Locking All Pages

A superuser process can request that all mappings within its address space be locked by a call to mlockall(3C). If the flag MCL_CURRENT is set, all the existing memory mappings are locked. If the flag MCL_FUTURE is set, every mapping that is added to an existing mapping or that replaces an existing mapping is locked into memory.

Recovering Sticky Locks

A page is permanently locked into memory when its lock count reaches 65535 (0xFFFF). The value 0xFFFF is defined by implementation. This value might change in future releases. Pages that are locked in this manner cannot be unlocked. Reboot the system to recover.