PCLSRing

From Wikipedia, the free encyclopedia

This article or section is written like a personal reflection or essay and may require cleanup.
Please help improve it by rewriting it in an encyclopedic style. (September 2007)

PCLSRing (often also colloquially 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. One scenario causes particular complications:

Process A makes a time-consuming system call. By "time-consuming" is meant that the system needs to put Process A into a wait state and reschedule some other process for execution while waiting for the call to complete. A common example of such a call is an I/O operation.
While Process A is in this wait state, Process B tries to make some access into the state of Process A, for example send it a signal.

The question is, 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).

If the system call cannot complete before the access, then it must be restartable. This means that the program counter 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 among other things 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. Then, after the access by Process B, Process A can resume execution, and the system call automatically resumes from where it left off.

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.

[edit] Asynchronous approaches

Of course, another entirely different approach is possible. It is implicit in the above discussion that the system call has to be synchronous--that is, the calling process has to be forced to wait for the operation to complete. But there is no essential reason for this: in the OpenVMS operating system, all I/O and other such 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.

For convenience, OpenVMS provides alternative "start operation and wait for completion" synchronous versions of all time-consuming system calls. These are implemented essentially 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 simply see it about to (re)enter the wait-for-event-flag call.

[edit] References

This article does not cite any references or sources. (September 2007)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.