Developing Software

This section briefly describes tools for input, processing, and output.

File and Record Locking

You lock files, or portions of files, to prevent the errors that can occur when two or more users of a file try to update information at the same time.

File locking and record locking are really the same thing, except that file locking implies that the whole file is affected, while record locking means that only a specified portion of the file is locked. (In the SunOS 5.x system, file structure is undefined: a record is a concept of the programs that use the file.)

Read and Write Locks

Two types of locks are available: read locks and write locks. When a process places a read lock on a file, other processes can also read the file but all are prevented from writing to it--that is, changing any of the data. When a process places a write lock on a file, no other processes can read or write in the file until the lock is removed. Write locks are also known as "exclusive locks." The term "shared lock" is sometimes applied to read locks.

Mandatory and Advisory Locking

Mandatory locking means that the discipline is enforced automatically for the functions that read, write, or create files. This is done through a permission flag established by the file's owner (or the superuser) and enforced by the kernel.

Advisory locking means that the processes that use the file take the responsibility for setting and removing locks as needed.

The principal weakness in mandatory locking is that the lock is in place only while the single function is being called. It is extremely common for a single transaction to require a series of reads and writes before it is complete. In cases like this, this transaction must be viewed as an indivisible unit.

The preferred way to manage locking in this case is to make certain the lock is in place before any I/O starts, and that it is not removed until the transaction is done. Advisory locking would be more appropriate than mandatory locking in this instance.

Also see the fcntl(2), fcntl(5), lockf(3C), and chmod(2) manual pages. The fcntl(2) function performs file and record locking (although it isn't limited to that only). The fcntl(5) page describes the file control options. The subroutine lockf(3C) can also be used to lock sections of a file or an entire file. The chmod(2) function is used to set or clear mandatory locking mode.

Interprocess Communications

Pipes, named pipes, and signals are all forms of interprocess communication. The SunOS 5.x system offers three additional facilities for interprocess communications (IPC):

messages	Communication is in the form of data stored in a buffer. The buffer can be either sent or received.
semaphores	Communication is in the form of positive integers with a value between 0 and 32,767. Semaphores may be contained in an array the size of which is determined by the system administrator. The default maximum size for the array is 25.
shared memory	Communication takes place through a common area of main memory. One or more processes can attach a segment of memory and as a consequence can share whatever data is placed there.

The following sets of IPC functions are described in Section 2 of the man Pages(2): System Calls:

msgget      semget      shmget
msgctl      semctl      shmctl
msgop       semop       shmop

Each "get" function returns to the calling program an identifier for the type of IPC facility that is being requested.

The "ctl" functions provide a variety of control operations that include obtaining (IPC_STAT), setting (IPC_SET), and removing (IPC_RMID) the values in data structures associated with the identifiers picked up by the get calls.

The "op" manual pages describe calls that are used to perform the particular operations characteristic of the type of IPC facility being used. The msgop page describes calls that send or receive messages. The semop operations increment or decrement the value of a semaphore, among other functions. The shmop operations attach or detach shared memory segments.

For more information, see section 2 of the man Pages(2): System Calls.

Process Scheduler

The system scheduler determines when processes run. It maintains process priorities based on configuration parameters, process behavior, and user requests; it uses these priorities to assign processes to the CPU.

Scheduler functions give users absolute control over the order in which certain processes run and the amount of time each process may use the CPU before another process gets a chance.

By default, the scheduler uses a time-sharing policy. A time-sharing policy adjusts process priorities dynamically in an attempt to give good response time to interactive processes and good throughput to CPU-intensive processes.

The scheduler offers an alternate real-time scheduling policy as well. Real-time scheduling allows users to set fixed priorities-- priorities that the system does not change. The highest priority real-time user process always gets the CPU as soon as it can be run, even if other system processes are also eligible to be run. A program can therefore specify the exact order in which processes run. You can also write a program so that its real-time processes have a guaranteed response time from the system.

For most SunOS 5.x system environments, the default scheduler configuration works well and no real-time processes are needed: administrators need not change configuration parameters and users need not change scheduler

properties of their processes. However, for some programs with strict timing constraints, real-time processes are the only way to guarantee that the timing requirements are met.

For more information, see priocntl(1), priocntl(2) and dispadmin(1M) of the man Pages(2): System Calls.

Memory Management

The operating system includes a complete set of memory-mapping mechanisms. Process address spaces are composed of a vector of memory pages, each of which can be independently mapped and manipulated. The memory-management facilities:

• Unify system operations on memory
• Provide a set of kernel mechanisms powerful and general enough to support the implementation of fundamental system services without special-purpose kernel support
• Maintain consistency with the existing environment, in particular using the file system as the name space for named virtual-memory objects

The system virtual memory consists of all available physical memory resources including local and remote file systems, processor primary memory, swap space, and other random-access devices. Named objects in the virtual memory are referenced though the file system. However, not all file system objects are in the virtual memory; devices that the SunOS operating system cannot treat as storage, such as terminal and network device files, are not in the virtual memory. Some virtual memory objects, such as private process memory and shared memory segments, do not have names.

The Memory Mapping Interface

You can access to the facilities of the virtual memory system through several sets of functions:

• mmap establishes a mapping between the process address space and a virtual memory object
• mprotect assigns access protection to a block of virtual memory
• munmap removes a memory mapping

• getpagesize returns the system-dependent size of a memory page
• mincore tells whether mapped memory pages are in primary memory

---

Note - It is better to use the memory management routines to implement shared memory than to use the advanced interprocess communication functions.

---

For more information, see the mmap(2), mprotect(2), munmap(2), getpagesize(3B), and mincore(2)of the man Pages(2): System Calls.