System Services

1. System Services • System services are functions that the operating system offers to perform on behalf of application programs. For example, a compiler will translate any request for input or output in a high level language to one of the most common system services, read() and write() • System services are written and called as C functions • If called from a C program the processor changes from user mode to kernel mode • System calls return value of -1 if successful, 0 or other if not. • If system call fails it returns a number to errno indicating the type of failure. • Use perror() to display

2. Processes • Definition - a process is a program in operation • A reasonable analogy is baking a cake. • The recipe for the cake is analogous to the program • The process in the kitchen from obtaining the ingredients, mixing, baking and eating is analogous to the process. • If the process is held up – we’ve run out of sugar. The process is swapped out and a new one loaded (prepare the vegetables for main course i.e. a new process). • This swap will require that we need to put away all the resources for baking the cake and get out new one for preparing main course – although some may be the same – process resources • We will also need to keep a record of where we are – process status

3. Two things to note about processes: • There may be more than one program per process – programs are frequently written separately and called during runtime. • A program may be involved with one or more processes - switching on the oven and putting the food into it may be common and so called from other processes.

4. Processes Dispatch Enter Not Running Exit Running Pause Figure 1 State Transition Diagram Queue Exit Enter Dispatch Processor Pause Figure 2 Queuing Diagram

5. The Five State Model • Running – the process is being executed. • Ready – the process is sitting in a queue waiting its turn. • Blocked – the process is waiting for I/O or some other service. • New – the process has been created but not added to the pool of executable processes. • Exit – released from the pool of executable processes

6. Dispatch Release Admit New Ready Running Exit Timeout Event Occurs Event Wait Blocked Figure 3 Five Process Model Release Processor Ready Queue Admit Dispatch Timeout Event Occurs Event Wait Blocked Queue Figure 4 Single Blocked Queue

7. Release Processor Ready Queue Admit Dispatch Figure 5 Timeout Event 1 queue Event 1 Wait Event 2 queue Event 2 Wait Event n queue Event n Wait Dispatch Release Admit New Ready Running Exit Timeout Event Occurs Activate Event Wait Figure 6 Suspend Blocked Suspend

8. 7 Stage Process Model New Activate Dispatch Release Ready suspend Ready Running Exit Suspend Timeout Event Occurs Event Occurs Event Wait Activate Blocked suspend Blocked Suspend

9. Process Transitions • Blocked  Blocked, suspend – If no processes have received I/O then a process is moved to secondary storage. • Blocked, suspend  Ready, suspend – a process is switched when it receives the event it has been waiting for. • Ready  Ready, suspend – this may occur in order to free up a sufficiently large block in main memory. • New  Ready, suspend and New  Ready – if a new process goes firstly to ready, suspend it gives the operating system time to create the necessary tables before it is swapped to the ready queue. If the process goes directly to the ready queue then creating tables with a "just in time" philosophy will reduce overheads. • Blocked, suspend  Blocked – this scenario sounds daft. However if a process terminates, freeing up some main memory while a process in the Blocked, suspend is of higher priority than the others and the operating system has reason to believe that the blocking event may occur soon, then it is not so daft. • Running  Ready, suspend – if the operating system if preempting a process because a higher priority process in the blocked, suspend queue has become unblocked, then the operating system could move it directly to ready suspend

10. In Unix, all processes are created with the system call fork(). This is without exception. What fork() does is the following: It creates a new process which is a copy of the calling process. That means that it copies the caller's memory (code, globals, heap and stack), registers, and open files. The calling process returns from fork() with the pid of the newly created process (which is called the "child" process. The calling process is called the "parent" process). The newly created process, as it is a duplicate of the parent, also returns from the fork() call (this is because it is a duplicate -- it has the same memory and registers, and thus the same stack pointer, frame pointer, and program counter, and thus has to return from the fork() call). It returns with a value of zero. This is how you know what process you're in when fork() returns. main() { int i; printf("simpfork: pid = %d\n", getpid()); i = fork(); printf("Did a fork. It returned %d. getpid = %d. getppid = %d\n", i, getpid(), getppid());} When it is run, the following happens: UNIX> simpforksimpfork: pid = 914 Did a fork. It returned 915. getpid = 914. getppid = 381 Did a fork. It returned 0. getpid = 915. getppid = 914UNIX>

11. The system call exec transforms the calling process by loading a new program into its memory space. If the exec is successful the calling program is completely overlaid by the new program, which is then started from its beginning. The result can be regarded as a new process, but one that is given the same PID as the calling process. execdoes not create a sub-process to run concurrently with the calling process. The old program is completely obliterated by the new program. Below is an example: main() { printf("executing ls\n"); execl("/bin/ls", "ls", "-l", (char *)0); perror("execl failed to run ls"); exit(1); }

12. printf(…..); execl(“/bin/ls”…..); PC BEFORE AFTER /* first line of ls */ PC

13. Android Life Cycle of an Activity

14. Android Life Cycle • OnCreate - this is the first method to be called when an activity is created. OnCreate performs any startup initialisations that may be required  • OnStart - called when the activity is becoming visible to the user. Android will call OnResume immediately after this method  • OnResume - the system calls this method when the Activity is ready to start interacting with the user. • Analogy - onPause() is when I come to a temporary stop. When I come to a red light I pause...the light goes green and I resume. Another red light and I pause, then green so I resume. The onPause() ->onResume() ->onPause() ->onResume() loop is a tight one and occurs many times through my journey. • OnPause - called when the system is about to start resuming a previous activity. If the user does not interact with the phone the screen will fade and the phone lock – this is also in OnPause • OnStop - called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one

15. OnRestart - called after your activity has been stopped, prior to it being started again. • OnDestroy - the final call you receive before your activity is destroyed

16. Scheduling • The long-term scheduler (or dispatcher) selects processes from this pool and loads them into memory for execution. • The short-term scheduler (or CPU scheduler) selects from among the processes that are ready to execute, and allocates the CPU to one of them. • Often, the short-term scheduler executes at least once every 100 milliseconds. • The long-term scheduler, executes much less frequently e.g minutes between the creation of new processes in the system. • The long-term scheduler controls the degree of multiprogramming (the number of processes in memory). • An I/O-bound process is one that spends more of its time doing I/O than it spends doing computations. • A CPU-bound process, on the other hand, is one that generates I/O requests infrequently, using more of its time doing computation than an I/O-bound process uses. • If all processes are I/O bound, the ready queue will almost always be empty, and the short-term scheduler will have little to do. • If all processes are CPU bound, the I/O waiting queue will almost always be empty, devices will go unused, and again the system will be unbalanced. • The system with the best performance will have a combination of CPU-bound and I/O-bound processes. • .

17. Threads • Instead of completely suspending the process if we require a resource we could just suspend part of the process and carry on with a different part. • So if we require, the butter to continue, we could suspend this part of the process and move back to weighing out the flour for the next batch of cakes. • This would reduce the overheads substantially as now we still have to save some of the status but don’t need to relinquish the resources like spoons bowls etc. • The process will still be using the same files, memory locations, devices etc – it is just jumping to a different location in the program code. This idea is known as multi-threading and each unit of execution is called a thread. • However, process still needs to save status information – state of registers, program counter, stack etc.

18. Process resource management in Unix • Working directory. • Program instructions • Registers • Stack • Heap • Process ID, process group ID, user ID, and group ID • File descriptors • Environment • Signal actions • Shared libraries

19. Process Control Block • Process Identification • Identifier of this process • Identifier of parent process • User Identifier • Processor State Information • User visible registers • Control and status registers • Program counter • Condition codes • Status information • Stack pointers • Process Control Information • Scheduling and state information • Process state – ready, running,blocked etc. • Priority • Scheduling related information e.g. waiting time • Event – identity of the event it is waiting for • Data structuring • Processes may be linked • Interprocess communication • Flags, signals associated with processes • Process privileges • e.g. memory that may be accessed • Memory management • Pointers to page tables • Resource ownership • Opened files, history of processor usage

20. Thread resource management • Stack pointer • Registers • Scheduling properties (such as policy or priority) • Set of pending and blocked signals • Thread specific data

22. Microsoft Windows • A thread is Windows smallest kernel-level object of execution. • Processes in Windows can consist of one or more threads. • When a process is created, one thread is generated along with it, called the primary thread. • Can create other threads that share its address space and system resources but have independent contexts, which include execution stacks and thread specific data.

23. Thread States in Windows • Waiting state is the same as the Blocked state. • Initialised state identifies a thread that is in the process of being created but is not yet ready to run. • Terminated state indicates that the thread has ended but it’s resources have not been reclaimed by the system. • Standby when it is between the time it is selected by the scheduler and time it is given to the CPU (it is in the queue). • Transition state identifies that the thread is no longer blocked on the condition that it made to enter the Waiting state.

24. UNIX process creation • fork() – this system call creates a clone of itself and returns its process ID (PID) number. • e.g int pid; pid = fork(); • exec() – there are a series of these call and they basically overlays a current process with a program of your choice. • Hence you can create a child process using fork() and then overlay it to produce a new process

25. The End

26. #include <stdio.h> fatal(char *s) { perror(s); exit(1); } main() { int pid; pid = fork(); if (pid > 0) { wait((int *)0); printf("ls completed\n"); exit(0); } if (pid == 0) { execl(" /bin/ls", "ls", "-l", (char *)0); fatal("execl failed"); } fatal ("fork failed"); }

27. When a system call is identified a C library routine runs which assigns the particular system call a number and then causes a software interrupt. • This interrupt vector is called INT 0x80. • This causes the CPU to go to the appropriate entry in the interrupt descriptor table, changes to kernel mode and jumps to a common system call handler, known as system_call(). • It then uses the system call number stored in EAX to index into a system dispatch table, sys_call_table to find the address of the kernel code which executes that particular system service.