ПCLSRing: 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-шешімі: ашық қайта іске қосу
Егер жүйелік шақыру қолжетімділікке дейін аяқталмаса, оны қайта іске қосу қажет. Бұл контекст жүйелік шақыруға кірген сәттен сақталады, ал шақыру аргументтері операцияның қандай бөлігі орындалғанын көрсету үшін жаңартылады. I/O операциясы үшін бұл буфердің бастапқы мекенжайының бұрын берілген деректерге қарай жылжуын, ал берілуге тиіс деректердің ұзындығының сәйкесінше қысқаруын білдіреді. B процесімен өзара әрекеттесу аяқталғаннан кейін А процесі орындалуын жалғастырады және жүйелік шақыру тоқтаған жерден қайта басталады. Бұл техника бағдарламалық қамтамасызда PDP 10 аппараттық құралдарында істеген нәрсені имитациялайды. Кейбір PDP 10 командалары, мысалы BLT, үзіліс немесе бет қатесі салдарынан толық орындалмауы мүмкін. Команданы өңдеу барысында PDP 10 команда аргументтерін сақтайтын тіркегіштерді өзгертеді, содан кейін команданы жаңа аргументтермен қайта орындауға болады, осылай қалған жұмыс аяқталады. PCLSRing жүйелік шақыруларға да осы әдісті қолданады. Бұл кейбір қосымша күрделілікті талап етеді. Мысалы, пайдаланушы кеңістігіндегі жад беттері ITS жүйелік шақыру кезінде беттен шығарылмайды. Егер мұндайға рұқсат берілсе, жүйелік шақыру PCLSRed болғанда және аргументтерді жаңартуға тырысқанда, аргументтерді қамтитын бет болмауы мүмкін, соның салдарынан жүйелік шақыру тоқтатылып, 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 операциялық жүйесінде қолданылатын тәсілмен салыстырыңыз, онда операцияны қайта бастау мүмкіндігі бар, бірақ ол көзге көрінбейді. Оның орнына, I/O операциясы нақты көшірілген байттар санын қайтарады (немесе егер операция бір де бір байт көшірілмей тұрып үзілген болса, 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 операциялық жүйесінде барлық I/O және басқа уақытты көп алатын операциялар бастапқыда асинхронды болып келеді, яғни жүйелік шақырудың мағынасы – "операцияны бастап, ол аяқталғанда осы хабарламалардың бірін немесе бірнешеуін беру" және содан кейін шақырушыға дереу қайтару. Қолжетімді хабарламалардың стандартты жиынтығы бар (мысалы, оқиға белгісін қою немесе асинхронды жүйелік қақтыруды жіберу), сондай-ақ процесті күту кезінде тоқтатуға арналған жүйелік шақырулар жиынтығы да бар, олар а) ITS түсінігінде толыққанды қайта іске қосылады және б) уақытты көп алатын жүйелік шақырулар жиынтығынан әлдеқайда аз. 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.