Process Control: Signals, Alarms, and Synchronization

1. Task Control:Signals and AlarmsChapter 7 and 8 B. Ramamurthy

2. Multi-tasking • How to create multiple tasks? Ex: Xinu create() • How to control them? • ready() • resched() • How to synchronize them? How to communicate among them? • XINU: semaphores, send and receive messages • How to (software) interrupt a process? signals

3. Examples • Consider g++ myProg.c • You want to kill this process after you started the compilation..hit cntrl-C • Consider execution of a program called “badprog” >badprog It core dumps .. What happened? The error in the program results in a signal to kernel to stop and dump the offending code • Consider “kill –p <pid>” • Kill issues a termination signal to the process identified by the pid

4. Linux Processes • Similar to XINU Procs. • Lets understand how to create a linux process and control it. • Chapter 7 and 8 of text book. • Chapter 7 : multi-tasking • Chapter 8: Task communication and synchronization

5. Process creation • Four common events that lead to a process creation are: 1) When a new batch-job is presented for execution. 2) When an interactive user logs in / system initialization. 3) When OS needs to perform an operation (usually IO) on behalf of a user process, concurrently with that process. 4) To exploit parallelism an user process can spawn a number of processes.

6. Termination of a process • Normal completion, time limit exceeded, memory unavailable • Bounds violation, protection error, arithmetic error, invalid instruction • IO failure, Operator intervention, parent termination, parent request, killed by another process • A number of other conditions are possible. • Segmentation fault : usually happens when you try write/read into/from a non-existent array/structure/object component. Or access a pointer to a dynamic data before creating it. (new etc.) • Bus error: Related to function call and return. You have messed up the stack where the return address or parameters are stored.

7. Process control • Process creation in unix is by means of the system call fork(). • OS in response to a fork() call: • Allocate slot in the process table for new process. • Assigns unique pid to the new process.. • Makes a copy of the process image, except for the shared memory. • both child and parent are executing the same code following fork() • Move child process to Ready queue. • it returns pid of the child to the parent, and a zero value to the child.

8. Process control (contd.) • All the above are done in the kernel mode in the process context. When the kernel completes these it does one of the following as a part of the dispatcher: • Stay in the parent process. Control returns to the user mode at the point of the fork call of the parent. • Transfer control to the child process. The child process begins executing at the same point in the code as the parent, at the return from the fork call. • Transfer control another process leaving both parent and child in the Ready state.

9. Process Creation (contd.) Parent process create children processes, which, in turn create other processes, forming a tree of processes Generally, process identified and managed via a process identifier (pid) Resource sharing Parent and children share all resources Children share subset of parent’s resources Parent and child share no resources Execution Parent and children execute concurrently Parent waits until children terminate

10. Process Termination Process executes last statement and asks the operating system to delete it (exit) Output data from child to parent (via wait) Process’ resources are deallocated by operating system Parent may terminate execution of children processes (abort) Child has exceeded allocated resources Task assigned to child is no longer required If parent is exiting Some operating system do not allow child to continue if its parent terminates All children terminated - cascading termination

11. Task State Diagram Task admitted New Ready Resources allocated Dispatched; cpu allocated Event occurred Task exit Blocked Run Waiting for event

12. Resources & Critical Resources • Shared resources: need mutual exclusion • Tasks cooperating to complete a job • Tasks contending to access a resource • Tasks synchronizing • Critical resources and critical region • A important synchronization and mutual exclusion primitive / resource is “semaphore”

13. Critical sections and Semaphores • When multiples tasks are executing there may be sections where only one task could execute at a given time: critical region or critical section • There may be resources which can be accessed only be one of the processes: critical resource • Semaphores can be used to ensure mutual exclusion to critical sections and critical resources

14. Semaphores See semaphore.h of xinu

15. Semaphores in exinu • #include <kernel.h> • #include <queue.h> /**< queue.h must define # of sem queues */ • /* Semaphore state definitions */ • #define SFREE 0x01 /**< this semaphore is free */ • #define SUSED 0x02 /**< this semaphore is used */ • /* type definition of "semaphore" */ • typedefulong semaphore; • /* Semaphore table entry */ • struct sentry • { • char state; /**< the state SFREE or SUSED */ • short count; /**< count for this semaphore */ • queue queue; /**< requires q.h. */ • };

16. Semaphores in exinu (contd.) • extern struct sentry semtab[]; • /** • * isbadsem - check validity of reqested semaphore id and state • * @param s id number to test; NSEM is declared to be 100 in kernel.h • A system typically has a predetermined limited number of semaphores • */ • #define isbadsem(s) (((ushort)(s) >= NSEM) || (SFREE == semtab[s].state)) • /* Semaphore function declarations */ • syscall wait(semaphore); • syscall signal(semaphore); • syscallsignaln(semaphore, short); • semaphore newsem(short); • syscallfreesem(semaphore); • syscallscount(semaphore);

17. Definition of Semaphores functions • static semaphore allocsem(void); • /** • * newsem - allocate and initialize a new semaphore. • * @param count - number of resources available without waiting. • * example: count = 1 for mutual exclusion lock • * @return new semaphore id on success, SYSERR on failure • */ • semaphore newsem(short count) • { • irqmask ps; • semaphore sem; • ps = disable(); /* disable interrupts */ • sem = allocsem(); /* request new semaphore */ • if ( sem != SYSERR && count >= 0 ) /* safety check */ • { • semtab[sem].count = count; /* initialize count */ • restore(ps); /* restore interrupts */ • return sem; /* return semaphore id */ • } • restore(ps); • }

18. Semaphore: newsem contd. • /** • * allocsem - allocate an unused semaphore and return its index. • * Scan the global semaphore table for a free entry, mark the entry • * used, and return the new semaphore • * @return available semaphore id on success, SYSERR on failure • */ • static semaphore allocsem(void) • { • int i = 0; • while(i < NSEM) /* loop through semaphore table */ • { /* to find SFREE semaphore */ • if( semtab[i].state == SFREE ) • { • semtab[i].state = SUSED; • return i; • } • i++; • } • return SYSERR; }

19. Semaphore: wait(…) • /** • * wait - make current process wait on a semaphore • * @paramsem semaphore for which to wait • * @return OK on success, SYSERR on failure • */ • syscall wait(semaphore sem) • { • irqmaskps; • struct sentry *psem; • pcb *ppcb; • ps = disable(); /* disable interrupts */ • if ( isbadsem(sem) ) /* safety check */ • { • restore(ps); • return SYSERR; • } • ppcb = &proctab[currpid]; /* retrieve pcb from process table */ • psem = &semtab[sem]; /* retrieve semaphore entry */ • if( --(psem->count) < 0 ) /* if requested resource is unavailable */ • { • ppcb->state = PRWAIT; /* set process state to PRWAIT*/

20. Semaphore: wait() • ppcb->sem = sem; /* record semaphore id in pcb */ • enqueue(currpid, psem->queue); • resched(); /* place in wait queue and reschedule */ • } • restore(ps); /* restore interrupts */ • return OK; • }

21. Semaphore: signal() • /*signal - signal a semaphore, releasing one waiting process, and block • * @paramsem id of semaphore to signal • * @return OK on success, SYSERR on failure • */ • syscall signal(semaphore sem) • { • irqmaskps; • register struct sentry *psem; • ps = disable(); /* disable interrupts */ • if ( isbadsem(sem) ) /* safety check */ • { • restore(ps); • return SYSERR; • } • psem = &semtab[sem]; /* retrieve semaphore entry */ • if ( (psem->count++) < 0 ) /* release one process from wait queue */ • { ready(dequeue(psem->queue), RESCHED_YES); } • restore(ps); /* restore interrupts */ • return OK; • }

22. Semaphore: usage • Problem 1: • Create 3 tasks that each sleep for a random time and update a counter. • Counter is the critical resources shared among the processes. • Only one task can update the counter at a time so that counter value is correct. • Problem 2: • Create 3 tasks; task 1 updates the counter by 1 and then signal task 2 that updates the counter by 2 and then signals task 3 to update the counter by 3.

23. Problem 1 #include <..> //declare semaphore semaphore mutex1 = newsem(1); int counter = 0; //declare functions: proc1,proc1, proc3 ready(create((void *)proc1, INITSTK, INITPRIO, “PROC1",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc2, INITSTK, INITPRIO, “PROC2",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc3, INITSTK, INITPRIO, “PROC3",, 2, 0, NULL), RESCHED_NO);

24. Problem 1: multi-tasks void proc1() { while (1) { sleep (rand()%10); wait(mutex1); counter++; signal(mutex1); } } void proc2() { while (1) { sleep (rand()%10); wait(mutex1); counter++; signal(mutex1); } } //similarly proc3

25. Problem 1 Task 1 Task 2 Counter1 Task 3

26. Problem 2 semaphore synch12 = newsem(0); semaphore synch23 = newsem(0); semaphore synch31 = newsem(0); ready(create((void *)proc1, INITSTK, INITPRIO, “PROC1",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc2, INITSTK, INITPRIO, “PROC2",, 2, 0, NULL), RESCHED_NO); ready(create((void *)proc3, INITSTK, INITPRIO, “PROC3",, 2, 0, NULL), RESCHED_NO); signal(synch31);

27. Task flow

28. Signals • Signals provide a simple method for transmitting software interrupts to UNIX process • Signals cannot carry information directly, which limits their usefulness as an general inter-process communication mechanism • However each type of signal is given a mnemonic name; Ex: SIGINT • See signal.h for others • SIGHUP, SIGINT, SIGILL, SIGTRAP, SIGFPE, SIGKILL • SIGALRM (sent by kernel to a process after an alarm timer has expired) • SIGTERM • signal (signal id, function) simply arms the signal

29. Intercept Signals Task1 Task2 Two essential parameters are destination process identifier and the signal code number: kill (pid, signal) Signals are a useful way of handling intermittent data arrivals or rare error conditions.

30. Handling Signals • Look at the examples: • Catching SIGALRM • Ignoring SIGALRM • sigtest.c • sigHandler.c • pingpong.c • See /usr/include/sys/iso/signal_iso.h for signal numbers

31. Signals and Alarms #include <signal.h> unsigned int alarm( unsigned int seconds ); alarm(a); will start a timer for a secsonds and will interrupt the calling process after a secs. time(&t); will get you current time in the variable t declared as time_t t ctime(&t); will convert time to ascii format Alarm has a sigaction function that is set for configuring the alarm handler etc. sigaction(SIGALRM, &act, &oldact) ; the third paramter is for old action configuration

32. Sample programs • Starting new tasks in linux: page 165 • Programs in pages: 174-180 on signals and alarms • See demos directory for first • See page 175 for the second program • See page 178 … for the third program

33. Pingpong Parent PSIG 43 Child CSIG 42

34. Observe in pingpong.c • pause(): indefinite • sleep(): sleep is random/finite time • While loop • Signal handlers • Re-arming of the signals

35. Volatile (from code reading: last lecture) • A variable should be declared volatile whenever its value could change unexpectedly. In practice, only three types of variables could change: • Memory-mapped peripheral registers • Global variables modified by an interrupt service routine • Global variables within a multi-threaded application