Принцип Lusering счётчика команд (PCLSRing) в ITS: обеспечение возобновляемости системных вызовов.
PCLSRing
PCLSRing в ITS: принцип согласованности доступа процессов. Обеспечивает возобновление системных вызовов после прерываний, сохраняя контекст и обновляя аргументы.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
PCLSRing (также известный как Program Counter Lusering) — термин, используемый в операционной системе ITS для обозначения принципа обеспечения согласованности при обращении одного процесса к состоянию другого процесса.
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.
ITS-решение: прозрачный перезапуск
Если системный вызов не может быть завершен до осуществления доступа, он должен быть возобновляемым. Это означает, что контекст сохраняется до точки входа в системный вызов, а аргументы вызова обновляются, чтобы отразить ту часть операции, которая уже была выполнена. Для операции ввода-вывода это означает, что начальный адрес буфера должен быть сдвинут вперед на объем уже переданных данных, а длина данных для передачи должна быть соответствующим образом уменьшена. После завершения взаимодействия с процессом B, процесс A может возобновить выполнение, а системный вызов продолжится с того места, где он был прерван. Эта техника программно имитирует то, что PDP 10 делает аппаратно. Некоторые инструкции PDP 10, такие как BLT, могут не завершаться из-за прерывания или ошибки страницы. В процессе обработки инструкции PDP 10 изменяет регистры, содержащие аргументы инструкции, чтобы позже инструкцию можно было запустить снова с новыми аргументами, завершающими оставшуюся работу. PCLSRing применяет ту же технику к системным вызовам. Это требует дополнительной сложности. Например, в ITS страницы памяти в пользовательском пространстве не могут быть выгружены во время системного вызова. Если бы это было разрешено, то при возобновлении (PCLSR) системного вызова и попытке обновить аргументы для прерывания вызова, страница, содержащая аргументы, могла бы отсутствовать, и системный вызов был бы заблокирован, что помешало бы успешному завершению PCLSR. Чтобы предотвратить это, ITS не позволяет выгружать страницы памяти в пользовательском пространстве после первого доступа к ним во время системного вызова, и системные вызовы обычно начинаются с обращения к страницам в пользовательском пространстве, к которым они планируют получить доступ.
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-решение: перезапуск по запросу
Сравните это с подходом, используемым в операционной системе UNIX, где предусмотрена возможность возобновления, но она не является прозрачной. Вместо этого, операция ввода-вывода возвращает количество фактически переданных байтов (или ошибку EINTR, если операция была прервана до передачи каких-либо байтов), и приложение должно самостоятельно проверять это и управлять возобновлением операции до тех пор, пока не будут переданы все байты. Ричард П. Габриэль привел это в качестве примера принципа "чем хуже, тем лучше" в философии UNIX.
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.
Асинхронные подходы
Возможен другой подход. Из вышесказанного следует, что системный вызов должен быть синхронным – то есть вызывающий процесс должен ждать завершения операции. Однако это не обязательно: в операционной системе OpenVMS все операции ввода/вывода и другие длительные операции по своей природе асинхронны, что означает, что семантика системного вызова заключается в "запуске операции и выполнении одного или нескольких уведомлений по её завершении", после чего управление немедленно возвращается вызывающему процессу. Существует стандартный набор доступных уведомлений (например, установка флага события или передача асинхронной системной ловушки), а также набор системных вызовов для явной приостановки процесса в ожидании этих уведомлений, которые a) полностью восстанавливаемы в смысле ITS и b) значительно меньше по количеству, чем набор фактических длительных системных вызовов. OpenVMS предоставляет альтернативные синхронные версии всех длительных системных вызовов, реализуемые как "выполнение фактической асинхронной операции", за которым следует "ожидание установки флага события". Любой доступ к контексту процесса в течение этого времени покажет, что он собирается (повторно) войти в вызов ожидания флага события.
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.