To browse Academia. Log in with Facebook Log in with Google. Remember me on this computer. Enter the email address you signed up with and we'll email you a reset link. Need an account? Click here to sign up. Download Free PDF. Synchronization under a commercial operating system Software: Practice and Experience, Jorn Bo Jensen.
A short summary of this paper. Download Download PDF. Translate PDF. This paper shows how to implement these principles under a typical commercial operating system which provides incomplete synchronization operations. The problem of synchronizing erroneous tasks is discussed briefly. When designing a real-time system for a particular computer, you then have three choices : 1. T o develop an operating system of your own.
To use a commercially available operating system and try to implement the well- known principles. T o replace the well-known principles by ad hoc programming. The authors have had long experience with the first choice, which gave high-quality dedicated systems. In order to follow choice l , we would have to develop or maintain several com- pilers, editors, etc.
And that is extremely more costly than developing an operating system for a dedicated system. Consequently we had to consider the second choice more seriously. With this given, we tried to implement mutual exclusion and semaphore synchronization among tasks jobs running under RSX. If it could be done efficiently, a major problem would be solved.
Two operations provide simple stop and start of tasks: suspend Stops the calling task temporarily until it is started by another task. RAVN Another group of operations provides indivisible setting and testing of flags or indivisible testing and suspension stopping.
But no operation provides setting, testing and suspension as one indivisible operation semaphores can be considered as providing just that. Still other operations provide a kind of message communication between tasks, but the pool of messages is common for all tasks. This implies that an erroneous user task can monopolize the pool and prevent important tasks from communicating.
All operations are rather time consuming, so an implementation of mutual exclusion based on them tended to involve too high an overhead, with the result that programmers had to circumvent mutual exclusion in cases where it would be the natural tool. This paper shows how to implement mutual exclusion and general synchronization efficiently by means of unconditional stop and start operations suspend and resume.
I n addition, the tasks involved need access to a common area. Protection against independent user tasks is arranged by not allowing these tasks to address the common area-a facility provided by RSX and the hardware. T h e solution is efficient because it only calls the operating system to stop and start tasks-and only when stopping and starting is the natural consequence of the synchroniza- tion. As the solution is based on the simple stop and start, it can be implemented under a wide range of operating systems.
T h e implementation outlined here is now being used by Brown Boveri in a new line of process control systems. T o our surprise this is not possible directly, as will be shown below. Consider a task Q which wants to suspend itself until task R wakes it up. T h e problem is to perform update, test and suspend decision indivisibly. At this moment it may happen that R gets the CPU and runs. R may then try to resume Q, but in vain, because Q has not yet suspended. This is the race condition described by Lampson.
This clearly is a form of busy waiting. Another way is to let R force Q to bypass the suspend. This cannot be expressed in a high-level language, but it is often possible on the level of machine language.
We will first describe these two repairs of the race condition. Later we will show how each of the repairs can form the basis for a lock controlling mutual exclusion. Finally, we will use the lock to complete the general synchronization problem, making sure that common variables are tested and updated indivisibly.
Repair 1: extended resume Many practitioners overcome the race condition by letting all tasks run periodically. For instance, R will periodically repeat the algorithm above, and sooner or later Q will be resumed. This, however, is an example of ad hoc programming, because the algorithm relies on non-local scheduling of the task.
Such principles would make it difficult to use the same program piece in different tasks. We will not depend on periodical tasks or other non-local scheduling, we can do a local form of busy waiting. Let us assume a little help from the operating system: resume Q gives a result showing whether Q could be resumed i.
This way of programming an extended resume is typical, but variations are possible depending on the actual operating system. Repair 2: forced bypass If Q is just before the suspend-instruction point D , it seems to be too late for R to prevent Q from suspending. However, R may change the very suspend-instruction in Q to a dummy instruction. The processes are using the same resource here i. In the first approach, the process P1 executes first and then the process P2 starts executing.
But in the second case, the process P1 was stopped after executing one instruction and after that the process P2 starts executing. And here both the processes are dealing on the same resource i. Here, the order of execution of processes changes the output. All these processes are in a race to say that their output is correct. This is called a race condition. The code in the above part is accessed by all the process and this can lead to data inconsistency.
So, this code should be placed in the critical section. The critical section code can be accessed by only one process at a time and no other process can access that critical section code. All the shared variables or resources are placed in the critical section that can lead to data inconsistency. All the Critical Section problems need to satisfy the following three conditions:. So, in order to remove the problem of race condition, there must be synchronization between various processes present in the system for its execution otherwise, it may lead to data inconsistency i.
That's it for this blog. Hope you learned something new today. What is Process? What is Device Driver? What is Binary Tree? What is Database? Control Chart : Graphical presentation of process data over time Natural Variations : Variability that affects every production process to some Assignable Variation : Variation in a production process that can be X Chart : Quality control chart for variables that indicates when R Chart : Control chart that tracks the range within a Learn More Related to Synchronization Definition System Bus : Bus used to interconnect major computer components Thrashing : Phenomenon in virtual memory schemes, in which the
0コメント