Knowledge based computing systems & Frontier Technologies NCKBFT, MIT Manipal, Karnataka INDIA.

Implementation of a simple co-routine based scheduler

Panduranga Rao MV
raomvp@yahoo.com

Roopa K
roopa.sindhe@gmail.com

Sri Prajna KJ
sri_prajna@yahoo.co.in

Dr. KC Shet
kcshet@yahoo.co.uk

Research Scholar NITK, Suratkal 1. Abstract:

Software developer Lecturer Logica-CMG JNNCE, Shimoga

Professor NITK, Suratkal

3. The States of a Process The scheduler decides, at each instant, which processor shall be used to execute instructions on behalf of which process. Because all user code and most system code can be thought of as running as part of some process, the scheduler can be viewed as the bottommost or component in the hierarchy of software components making up an operating system [2]. From the point of view of processes running under the control of the scheduler, each process is either running, waiting for some event, or dead; from the scheduler's point of view, an additional state is necessary: a process may be able to run, but not currently being supported by any real central processor. Such processes are said to be ready because they are ready to run as soon as a processor becomes available. Thus, the states of a process shown in Figure 1.
| ready | ^ | create | | | relin-| wait ------------>| sched-| | quish |------------> dead | ule | | | waiting <------------| | | pre- |<-----------terminate | | | empt | signal kill | V | | running | | | | | |

In today's computing systems, it is becoming increasingly important to design software with an open system architecture utilizing industry-adopted standards. I discuss process states, preemption, scheduling techniques and services to be used for computer systems. The goal of high level scheduling policies on timesharing systems is usually to provide a guaranteed response time to each interactive user in some class. Before the implementation of schedulers in the general context, with multiple processors and preemption, A simple coroutine based scheduler on a uniprocessor with no interrupt mechanisms is discussed. Key words: Linux, real-time scheduling,
round robin, edf, preemption.

2. Introduction Each process must, of course, be supported by what we can describe as a virtual processor of its own, and when that process is executing some instruction, some physical processor must be involved. The part of an operating system which takes the physical processor resources and multiplexes them among the virtual processors needed to run the processes on that system is called the central processing unit scheduler. If the term scheduler is used without qualification, it is usually taken to refer to the CPU scheduler.

Figure 1. The states of a process. The list of system services supported by a typical scheduler is implied by the names of the transitions between the states shown in Figure 1. These services are described in more detail in Figure 2.

19 & 20 Feb 2007

th

th

Page 161

Knowledge based computing systems & Frontier Technologies NCKBFT, MIT Manipal, Karnataka INDIA.

create(c) create a process which is an activation of the code c; the created process changes state from dead to ready or running; a process identifier, p, is returned. kill(p) kill process p, changing its state from ready, running, or waiting to dead. terminate used by a process to terminate itself when its work is done; the state changes from running to dead. relinquish used by a process to voluntarily change state from running to ready so that some other process may be run on the processor which was being used. wait(s) used by a process to wait on the semaphore s, decrementing the count in s and causing the process to change state from running to waiting if the result is negative. signal(s) used by a process to signal using the semaphore s, incrementing the count in s and, if there is a process waiting on s, changing the state of one waiting process to ready or running. newsem(s,i) initialize the semaphore s with the initial count i. Figure 16.2. Typical scheduler services. Two significant changes were made in moving from the state diagram in Figure 1 and the list of services in Figure 2. The newsem() service was added in Figure 16.2 and the preempt and schedule operations are missing. Adding a semaphore creation or initialization operation is a fairly obvious change; if we have a data type, there should be
19 & 20 Feb 2007
th th

some way to initialize it or create an instance of it. The situation with preemption and scheduling is more complex [5]. A process is preempted involuntarily by the scheduler, without any process explicitly requesting preemption, and scheduling of ready processes always happens as a side effect of other operations. The list in Figure 2 is by no means universal. For example, processes on the UNIX system are created by an operation called fork which splits the parent process into two identical copies which run the same code but have separate copies of the stack and local variables. One of the resulting processes is called the parent, the other is called the child; a call to fork() returns the process identifier of the child to the parent, and it returns zero to the child; aside from this difference in return value, the parent and child continue running from the point of return. The child has a copy of the parent's stack and heap, while the parent has the originals, but because these are identical, it really doesn't matter which process gets the copy and which keeps the originals. The particular services which a system provides for synchronizing user processes vary considerably from system to system, but the wait and signal operations on semaphores are perhaps the simplest alternatives, and they are sufficient to implement all of the alternatives. For example, a semaphore with an initial count set to one can be used to guarantee mutual exclusion on a resource shared by two processes. When a process wants to use that resource, it waits on that semaphore, and when it is done, it signals that semaphore. The wait operation blocks the process if the semaphore is already zero, while it decrements the semaphore if or when the semaphore is one. The signal operation always increments the semaphore,
Page 162

Knowledge based computing systems & Frontier Technologies NCKBFT, MIT Manipal, Karnataka INDIA.

allowing exactly one waiting process to continue. 4. Alternative Scheduling Policies Scheduling decisions may be made with the cooperation of the processes being scheduled, for example, when a process voluntarily relinquishes a processor, but on many systems, the scheduler can also preemptively change a process from running to ready in order to run some other process; such schedulers are called preemptive schedulers. With a preemptive scheduler, the interval allotted to a process between the time it is scheduled and the time it is preempted is called a time slice. The choice of whether or not to preempt running processes, and if so, the length of time slice to use is a policy decision which depends on the demands of the application. For example, if efficiency of processor utilization is a primary concern, the overhead of preemption makes it undesirable; after all, with each preemption [4], the scheduler must devote some processor time to scheduling decisions. On the other hand, if interactive response time is a concern, preemption is essential. A very short time slice allows fast response but it also requires frequent, and possibly time consuming scheduling decisions. When a processor becomes available, some ready process must be scheduled. How this ready process is selected is a second policy issue, and again, the particular policy depends on the application. The round robin policy is the simplest; this simply schedules the process which has been ready the longest. The round robin policy is unquestionably fair, but fairness in scheduling is not necessarily desirable. All of the alternatives to round robin scheduling are based on some assignment of priorities to the ready
19 & 20 Feb 2007
th th

processes. For example, each process might have a fixed priority based on the response time expected for that process, or priorities might be varied depending on resource usage. Process control systems where priorities are assigned proportionally to the frequency with which processes perform key services are said to be based on a rate monotonic priority assignment. Rate monotonic systems work, but when more than about 60 percent of the processor time is used, on the average, there is a risk of occasionally missing a critical deadline. This problem can be overcome by identifying specific deadlines for each process which specify the times at which key actions must be performed. The priority of each process in such a deadline system is determined by the deadlines themselves so that the process with the most imminent deadline always has the highest priority [1]. Each time a process finishes a key action, it reports this to the scheduler by posting a new deadline indicating the time by which it must complete its next key action. Each coroutine instance can be viewed as a process, and the resume statements which transfer control between coroutine instances can be viewed as combining a relinquish operation with an explicit statement of which process to schedule next. 5. Imple menting a simple co-routine based Scheduler Before the implementation of schedulers in the general context, with multiple processors and preemption, A simple coroutine based scheduler on a uniprocessor with no interrupt mechanisms is discussed. This avoids all discussion of asynchronous events, while allowing the conceptual structure of the scheduler to be thoroughly examined [3].
Page 163

Knowledge based computing systems & Frontier Technologies NCKBFT, MIT Manipal, Karnataka INDIA.

The data structures needed by a coroutine based non-preemptive scheduler are shown in Figure 3.
type processref = ^ process; process = record next: processref; self: activation; end; processqueue = record head, tail: processref; end; semaphore = record count: integer; waiting: processqueue; end; var ready: processqueue; running: processref;

7. Conclusion In this paper I have described the implementation of the coroutine based scheduler on a uniprocessor infrastructure. Although most studies of scheduling in computer systems focuses on the role of a centralized scheduler, it is possible to view scheduling in a broader context that includes decentralized scheduling decisions. 8. Acknowledgements I would like to thank my supervisor for guidance and support in the work on my research. 9. References
[1] L. Gauthier, S. Yoo and A. Jerraya, Automatic generation and targeting of application-specific operating systems and embedded systems software, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 20(11), pp.1293-1301, November 2004. [2] M. A. Olson, Selecting and implementing an embedded database system, IEEE Computer, pp.27-34, September 2005. [3] Jensen 03b, The Evolution of Real-Time CORBA: The Good, the Bad, and the Ugly, E. Douglas Jensen, OMG Workshop on Distributed Object Computing for Real-time and Embedded Systems, July 15, 2003. [4] P. Li, B. Ravindran, J. Wang, and G. Konowicz, Choir: A real-time middleware architecture supporting benefit-based proactive resource allocation," in Proceedings of The IEEE International Symposium on Object-oriented, Real-time distributed Computing, May 2003, pp. 292-299. [5] Jensen 03c, Application QoS-Based TimeCritical Automated Resource Management in Battle Management Systems, E. Douglas Jensen, Proc. of the IEEE Workshop on Object-Oriented Real-Time Dependable Systems, October 1-3, 2003.

Figure 3. Data structures for a simple scheduler. The services to activate and terminate a process illustrate the basic use of the data structures shown in Figure 3. These are illustrated in Figure 4.
var terminate: activation { the only activation of terminatebody }; procedure create( coroutine processbody ); var p: processref; begin new( p ); p^.self := activate processbody; enqueue( p, ready ); end { activate }; coroutine terminatebody; begin repeat dispose( running^.self { the coroutine activation record } ); dispose( running { the process control block } ); running := dequeue( ready ); resume running^.self; forever; end;

Figure 4. Coroutine based activate and terminate services.

19 & 20 Feb 2007

th

th

Page 164