PCLSRing

PCLSRing (also known as PC 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 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, it 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 conplete, Process A can resume execution, and the system call resumes from where it left off.

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 seems in the above that the system call has to be synchronous--that is, the calling process has to wait for the operation to complete. There is no reason for this: 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.

References

External links

• 'PCLSRing: Keeping Process State Modular- (by Alan Bawden; an excellent description of the ITS implementation; from his homepage)