PCLSRing

PCLSRing (also known as Program Counter Lusering) is the term used in the ITS operating system for a consistency principle in the way one process accesses the state of another process.

Problem scenario

This scenario presents particular complications:

• Process A makes a time-consuming system call. By "time-consuming", it is meant that the system needs to put Process A into a wait queue and can schedule another process for execution if one is ready-to-run. A common example is an I/O operation.
• While Process A is in this wait state, Process B tries to interact with or access Process A, for example, send it a signal.

What should be the visible state of the context of Process A at the time of the access by Process B? In fact, Process A is in the middle of a system call, but ITS enforces the appearance that system calls are not visible to other processes (or even to the same process).

ITS-solution: transparent restart

If the system call cannot complete before the access, then it must be restartable. This means that the context is backed up to the point of entry to the system call, while the call arguments are updated to reflect whatever portion of the operation has already been completed. For an I/O operation, this means that the buffer start address must be advanced over the data already transferred, while the length of data to be transferred must be decremented accordingly. After the Process B interaction is complete, Process A can resume execution, and the system call resumes from where it left off.

This technique mirrors in software what the PDP-10 does in hardware. Some PDP-10 instructions like BLT may not run to completion, either due to an interrupt or a page fault. In the course of processing the instruction, the PDP-10 would modify the registers containing arguments to the instruction, so that later the instruction could be run again with new arguments that would complete any remaining work to be done. PCLSRing applies the same technique to system calls.

This requires some additional complexity. For example, memory pages in User space may not be paged out during a system call in ITS. If this were allowed, then when the system call is PCLSRed and tries to update the arguments so the call can be aborted, the page containing the arguments might not be present, and the system call would have to block, preventing the PCLSR from succeeding. To prevent this, ITS doesn't allow memory pages in User space to be paged out after they're first accessed during a system call, and system calls typically start by touching pages in User space they know they will need to access.

Unix-solution: restart on request

Contrast this with the approach taken in the UNIX operating system, where there is restartability, but it is not transparent. Instead, an I/O operation returns the number of bytes actually transferred (or the EINTR error if the operation was interrupted before any bytes were actually transferred), and it is up to the application to check this and manage its own resumption of the operation until all the bytes have been transferred. In the philosophy of UNIX, this was given by Richard P. Gabriel as an example of the "worse is better" principle.

Asynchronous approaches

A different approach is possible. It is apparent in the above that the system call has to be synchronous—that is, the calling process has to wait for the operation to complete. This is not inevitable: in the OpenVMS operating system, all I/O and other time-consuming operations are inherently asynchronous, which means the semantics of the system call is "start the operation, and perform one or more of these notifications when it completes" after which it returns immediately to the caller. There is a standard set of available notifications (such as set an event flag, or deliver an asynchronous system trap), as well as a set of system calls for explicitly suspending the process while waiting for these, which are a) fully restartable in the ITS sense, and b) much smaller in number than the set of actual time-consuming system calls.

OpenVMS provides alternative "start operation and wait for completion" synchronous versions of all time-consuming system calls. These are implemented as "perform the actual asynchronous operation" followed by "wait until the operation sets the event flag". Any access to the process context during this time will see it about to (re)enter the wait-for-event-flag call.