In the figure, P1 and P2 are two processes "Multiprocessor", ie, multiplexed in time in such a way that P1 and P2 are simultaneously in the eyes of the user, OS is the operating system or, more specifically, a routine responsible for producing the switching between processes. Each process runs continuously until the arrival of a TIMER interrupt (every 1 ms) which passes control to the OS.
We have seen in previous articles that a program can only exist as such in Storage, when loaded into memory, it creates an "instance" consists of two areas: one for code and other data for your area (Stack). We also saw that same program can be multi-instantiated, in which case it keeps in memory a single copy the code, but Stacks are created separately, one for each instance. By "process" we mean just that: an instance of a given program, in particular, P1 and P2 may be instances of the same program.
STATE OF EXECUTION
When a process is interrupted (the Timer), its "status of implementation" must be stored somewhere so that when the OS returns control, it can continue the exact ejecutación point where you left off.
At Heritage / 1, the interrupt mechanism itself provides the means to save the "state of execution." Indeed, when an interrupt occurs, the Program Counter (PC) and flags (F) are automatically saved in the Stack. But we saw that each process has its own stack so that at any given time there are several, one for each process in multiprocessing. However, for the interrupt mechanism, "Stack" is that the log structure pointed to by SP (Stack Pointer), and at the time of the interruption Stack SP is pointing to the interrupted program so that is where save (automatically ) PC and F.
Moral: The status of implementation of a given process is saved in their stack.
Disruption leads to OS, the first task is to save the state complete the process execution interrupted that is, save the rest of the records in their own Stack. At baseline, SP still points to the stack of the process, so the OS complete with successive saves PUSH instructions. Finally, the OS saves SP to a data structure itself.
OS The second task is to pass control to the next process in turn. It is sufficient to find out what that process and retrieve the corresponding Stack Pointer (ie, load SP with that value). Once done, Stack SP is pointing to the process in question where, as has been said, is saving his "state of execution." The OS is responsible for executing successive instructions then POP to retrieve the records he saved at the time, after which a RET instruction executed on the master (interrupt return). This statement automatically takes care of recovering PC, F, and pass control to the process in question, which completes the switching.
DATA STRUCTURE
To conduct its work in arbitration, the OS uses its own data structures. The following is only a first approximation as the structures as such have not been designed. PGM
In an arrangement (call PGM) is stored information about each program available. Remember to recycle programs in Storage, not in memory. To make the OS aware of its existence, is needed a configuration file where such programs are enrolled. The OS reads this file during loading and creates from it, the PGM which specify under what programs are available and where to find them in Storage. PROC
In an arrangement (call PROC) is stored information about the processes involved multiprocessing. Initially, the array will be empty or may contain information about operating system processes automatically launched (as Shell). Each array element specifies, among other things, the address in memory of the Code and the Stack of the process in question.
Whenever a process instance, creates a new element in the array PROC. If this is the first instance, the corresponding program is loaded from storage. The OS switching mechanism is guided by this arrangement for arbitration. SESSION
Assuming that the system can be accessed from several terminals at once, the concept of session is a "working day" from the perspective of the visitor. However, the session is not a concept inherent in multiprocessing. Talk about it later in an article devoted to "Multi-User."
OPERATING SYSTEM SERVICES
Apart from the arbitration rutuna multiprocessing we just saw, the OS offers other services, especially for applications such as access to perifiéricos, accommodation etc memory.
applications requesting these services through software interrupts (INT instruction), which we call "calls to the OS" or (in English) "System Calls".
When an application makes a System Call, the CPU passes control to the specified interrupt routine, which is part of the OS. The first thing this routine is to disable the timer interrupt to avoid being disturbed during their work. And this is important: an OS interrupt routine stops multiprocessing, that is, it paralyzes the system to concentrate entirely on the task of the OS.
These routines must therefore be short and concise. Their duties are such as memory allocation, etc peripheral initiation. Once he finished his brief work, the routine passes control to the heart of the OS who will take care then move to the next process in turn.
But the OS also offers FULL SUPPORT "long" that can not be written as short interrupt routines. Such is the case, for example, data processing routines such as: Management, búqueda, or perhaps a floating point arithmetic. These services are implemented as software operating system (to which we call services) and makes them participate in such processes multiprocessing ordinary. To make use of them, an application makes a system routine calls interrumpción which merely provides the bridge between the application and service.
RELATIONS RELATIONSHIP BETWEEN PROCESSES
As a process can request a service from the OS (which is, as we saw, another process), a process can also start another process not covered by the operating system. This applies, for example, run-time library "of language (on this particular issue back on other items).
Suppose there is a service to sort lists, call it QUICK-SORT. To use, a process must make a system call passing as argument the address of the list in question as well as its size. Surely, the process is not interested in further execution until QUICK-SORT has completed its work and that nothing can be done with a half-order list.
Remember that a service is involved multiprocessing, so that their work takes place "simultaneously" with the process that called it. So most likely the OS returns control to the process before the QUICK-SORT has completed its work, contrary to what is wanted.
The way around this is to build relationships of kinship between processes. In this case, the process in question is "father" of the instance (process) QUICK-SORT that the OS created upon request. And the rule is that the father stops until the child has finished executing.
"Stop a process" in multiprocessing means that their turn, the OS will not control him but the next process in turn. This is achieved through the use of "traffic lights" which in this case, puden located in the same array PROC.
Another advantage of parent-child relationships between processes refers to cleaning and maintenance: When a parent process dies, all his children should die, preventing imnecesariamente occupy the spectrum of multiprocessing.
PROCESSING MULTI-WIRE
The rule set out in section above (the father if the child stops running) is not strict but just an option. It may happen that a process need not wait for the results of the requested service. For example, printing a document as I continue with other calculations related to printing.
In this case, the application would make the system call specifying that you want to be stopped. As a result, a process would be "simultaneously" with their children, which is nothing but "multi-thread (multithreading).
MULTI-USER does not directly involve multiprocessing
Multi-User. On this theme abound in separate article due to its extension.
0 comments:
Post a Comment