Systems Programming/ C and UNIX

Transcription

1 Systems Programming/ C and UNIX A. Fischer CSCI 4547 / 6647 November 16, 2017 A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

2 Outline 1 Signals for Threads Signals 2 Signal Handling for Processes Signals and Waits A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

3 Signals for Threads Signals and Threads Signal Basics Listening for and Sending Signals Condition Variables A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

4 Signals for Threads Signals Signal Basics Code example: sigthread.c A signal is an integer code sent from one process or thread to another. A particular process decides which signals it will respond to. Those signals are defined by adding them individually to a signal set. A thread can wait() until it receives a signal from the defined set. An if statement is used to implement a signal handler for each member of the set. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

5 Signals for Threads Signals Defining and Using a Signal Set Code example: sigthread.c sigset_t set; // Set of signals we will catch sigemptyset(&set); // Initialize opaque-type object. sigaddset(&set, SIGQUIT); // Quit signal. sigaddset(&set, SIGUSR1); // User-defined sig 1 rc = pthread_sigmask(sig_block, &set, NULL); A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

6 Signals for Threads Signals Defining and Using a Signal Set 2 The pthread_sigmask() function examines and/or changes the calling thread s signal mask. The first parameter specifies what to set the signal mask to: SIG_BLOCK: Union of the current mask and set. SIG_SETMASK: set. SIG_UNBLOCK: Intersection of the current mask and the complement of set. If set is not NULL, it specifies a set of signals to be modified SIGKILL and SIGSTOP cannot be blocked, and will be silently ignored if included in the sig- nal mask. Return values: If successful, pthread_sigmask() returns 0. Otherwise, an error code is returned. It fails if the enum constant is not one of those defined. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

7 Signals for Threads Signals Listening for Signals Code example: sigthread.c pthread_kill sends a signal to a specified thread. In the child thread: rc = sigwait( &set, &rc ); In the parent thread: // Wake up all the children for(t=num_threads-1; t>= 0; t--){ pthread_kill( threads[t], SIGQUIT ); } Note: This can only be used when you are sure the threads are in a blocked state. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

8 Signals for Threads Signals A User-defined Signal Code example: badthread.c In main() pthread_kill( threads[2], SIGUSR1 ); In the child thread: rc = pthread_sigmask(sig_block, &set, NULL); rc = sigwait( &set, &sig ); if (sig == SIGUSR1) printf("oh Mama! It s me, thread #%ld! That hurts.\n", tid); else printf("hello Mama! It s me, thread #%ld! I just woke up.\n", tid); A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

9 Signals for Threads Signals Using a Condition Variable: produce3.c In global memory: pthread_cond_t notfull = PTHREAD_COND_INITIALIZER; pthread_cond_wait(&notfull &turn_mutex); pthread_cond_signal( &notfull ); A thread can use the wait and signal functions with a mutex lock to ensure that two conditions are simultaneously true. In a producer/consumer program, two condition variables are needed: notempty and notfull. pthread_mutex_lock( &turn_mutex ); while (!stopflag && q.count==bufsize) { pthread_cond_wait(&notfull, &turn_mutex); } if (!stopflag) {// Do the thread s normal task here.} pthread_cond_signal( &notempty ); pthread_mutex_unlock( &turn_mutex ); A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

10 Signal Handling for Processes Signals Catching Signals Handling the Signal A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

11 Signals Signals allow the manipulation of a process from inside itself, from its children, or from outside its domain. Some signals cause termination of a process. They might result from an irrecoverable error or from a user typing the interrupt character. Other signals provide information, rather than cause termination. They are used when the status of processes changes, or when input is ready at the control terminal. The SIGKILL and SIGSTOP signals cannot be caught or ignored. They are received and processed by the kernel. It is not possible to redefine the way they are handled. Several signals (such as SIGINT) have default handlers that terminate the process, others do not have a default action. kill -CODE pid sends the signal CODE to the process pid. kill pid means the same thing as kill -TERM pid A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

12 Traditional Meanings of Signals Many signals have customary interpretations, but a programmer can redefine their meanings. SIGKILL: Terminate the process immediately; it is out of control and not responding to normal signals. SIGSTOP: Pause a process until SIGCONT is received. SIGSTP ( Z): Sent to a process by its controlling terminal when the user asks to suspend the process. SIGINT ( C): Terminate the process gracefully. SIGTERM: Terminate the process gracefully, i.e. flush buffers, ask the user if he wishes to save his files, and close the files. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

13 More Signal Codes These signals can all be caught and redefined. Their default meanings are listed. SIGQUIT SIGALRM SIGHUP quit program and generate a dump terminate process; real-time timer expired terminate process; terminal line hangup SIGCHLD SIGBUS SIGSEGV child status has changed bus error segmentation violation SIGUSR1 User defined signal 1 SIGUSR2 User defined signal 2 A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

14 Catching Signals: siggy Many system-defined signals will terminate the process if they are not caught and handled. In the demo program, both the producer and consumer processes catch SIGINT. Catching and handling the signal requires three actions: Define the function that processes the signal. Define a signal handling structure. Attach the structure to the signal you want to catch. The program siggy shows how to set up these three parts. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

15 The Signal-handling Structure We need an object of type sigset_t to use as a mask. sigset_t emptyset; // Create a signal set. sigemptyset(&emptyset); // Initialize it to empty. Define an object of type struct sigaction: struct sigaction newact; newact.sa_handler = breakhandler; // handler to use newact.sa_mask = emptyset; // signals to disable newact.sa_flags = 0; // 0 = default Attach the action to the interrupt code: sigaction(sigint, &newact, NULL); // interrupt signal A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

16 Signal Handlers The function that processes the signal is normally short, and a lot like an exception handler. Many signal handlers supply user information and terminate the process. Others set memory variables that will enable the process to continue meaningfully. The parameter to the handler-function is the code number of the signal that was sent. Depending on what the handler does, it may not work properly to use high-level IO or any other library functions that have internal state. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

17 siggy s Signal Handler In siggy, we demonstrate the quick exit. This process prints a message using low-level output and writing to stderr. siggy s main loop (line 32) prints an infinite series of +. until the user types C to generate a SIGINT. When that interrupt happens, the breakhandler is called and siggy exits with an error code (1). void breakhandler(int sig) { char* message = " Process interrupted.\n"; write(2, message, strlen(message)); exit(1); } A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

18 Signals and Waits Using sigwait() The sigtest demo shows what happens when we reenter execution after catching a signal. We call sigwait() to put the process into a blocked state. To do so, we must define the set of signals that can end the wait. We need a sigset_t object: sigset_t sigset; sigemptyset(&sigset); sigaddset(&sigset, SIGINT); If we wanted to wake up for more than one reason, we could add more signal-types to the sigset. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

19 Signals and Waits Catch, Handle, and Continue The sigtest demo shows the ugly interaction between signals and waits. This function catches the signal, sets a flag to say that it happened, and writes to stderr. It does NOT kill the process. void siginthandler(int sig) { flag = true; printf(" Signal %d received\n", sig); } When a signal handler returns, control goes back to wherever it was when the signal happened. In sigtest, we prompt the user twice to enter a SIGINT. The first time we are executing an output loop, the second time we are in a sigwait(). A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20

20 Signals and Waits The Strange Behavior of sigtest On lines 44-45, we prompt the user for a signal, then execute a busy wait until the signal happens. Busy waits keep the CPU busy doing useless work. They should be avoided because they can severely damage performance in an application that uses multiple concurrent processes or threads. When the signal comes, the handler catches it and sets the flag. Then we leave the busy wait loop and provide feedback. Note that the flag has been set. After the second prompt (line 50), we call sigwait() and block. When the signal comes, it wakes us up but it DOES NOT call the signal handler. (The flag is not set.) This uncontrollable and unpredictable behavior makes signals very tricky to use. A. Fischer CSCI 4547 / 6647 Systems Programming Lecture /20 November 16, / 20