CSci4061: Introduction to Operating Systems
November 23, 2021
Computer Science & Engineering, University of Minnesota
Copyright By PowCoder代写 加微信 powcoder
• Grading to be released by today
• Regrading by 11/30
• Let us know if you have questions or any feedback
Last lecture
• Inter-process communication
• Issues with pipe and FIFO
• Introduced message queues and shared memory
• This lecture: Signals
Overview of signals
What is behind ‘Control+C’ to a running process?
What is behind ‘Control+C’ to a running process?
Apparently, it terminates a process
What is behind ‘Control+C’ to a running process?
Apparently, it terminates a process Specifically
• It causes the OS to send a signal to a running process • Usually the signal causes the process to terminate
• But the process may optionally “catch” the signal and do something more
What is a Signal?
• A software interrupt generated by the OS or processes • A software notification to a process of an event
• Signals are asynchronous
• Examples of events
• Exception or error, e.g.: bad memory access, divide-by-zero
• OS notification of an event, e.g.: alarm, child process termination, async-I/O
completion
• Can be generated by the user/another process. e.g.: Ctrl-C, process stop,
user-specified signal
What is a Signal (cont’d)
• Each signal name starts with SIG and corresponds to a specific event type. • Examples:
• SIGCHLD: Child terminated
• SIGSEGV: Segmentation fault
• SIGKILL: Kill signal
• SIGINT: Interrupt from keyboard
More signo: http://man7.org/linux/man-pages/man7/signal.7.html
Interrupts vs. Exceptions vs. Signals
• Interrupts are generated by hardware
• Example: interrupt generated by keyboard to type a character on screen • Asynchronous;
• Exceptions are interrupts which are generated by the processor; often result from software errors
• Example: Divide by zero
• Synchronous!
• Signals generated by software (kernel or processes) and sent to the process in the event of an exception or an interrupt
• It is a communication channel • Asynchronous
Why Signal?
Why Signal?
• To notify it of an event that occurred
• Computational and memory footprint for signals is small
• Particularly useful for small devices
• Signals are mediated by the kernel
• Can cause the interruption of a system call in progress
• Can ensure some signals cannot be ignored or blocked—important
• Well defined
Some terminologies
• A signal is generated when an event occurs
• Could be generated by the OS or by another process
• Signal is delivered when the notified process takes action
• Signal is pending between its generation and delivery, or called blocked
• The time window can be wide if a signal is blocked
• A process catches a signal if it executes a signal handler when the signal is delivered
Sending Signals: kill
Note: kill is something of a misnomer: it is also used for generating signals int kill(pid_t pid, int sig);
• Parameters:
• pid: Signal-receiving process
• Sender should have appropriate permissions • sig: Signal name. Example:
• SIGUSR1: miscellaneous signal
• SIGKILL: actually kill a process
• The corresponding kill command (wapper of kill()):
kill –s signal_name pid
kill -s USR1 3423
kill -9 3423
Handling Signals
• A receiving process can take one of three actions for a signal • Ignore:
• Throw away the signal
• Cannot ignore SIGKILL and SIGSTOP
• Delay the delivery of the signal
• Unblocking delivers a pending signal • Cannot block SIGKILL and SIGSTOP
• Set up a user function (through a function pointer) to be called when the signal is delivered
Discussion: Would SIGKILL cause denial-of-service by malware?
Discussion: Would SIGKILL cause denial-of-service by malware?
• Unix provides security mechanisms to prevent unauthorized users from killing other processes
• The owner of the signaling process must be the same as the owner of the receiving process or be the superuser
Further question: Whoud signals cause race conditions or corruptions? If yes, how to avoid them?
Blocking Signals
Blocking Signals and Why
• Blocking a signal means telling the operating system to hold it and deliver it later
• It is useful to block signals briefly, to prevent them from interrupting sensitive operations
• Example: You can use the sigprocmask() function to block signals while you modify global variables that are also modified by the handlers for these signals
• Otherwise: potential corruption
How to Block Signals: Signal Sets and Signal Masks
Idea: creating a signal set and specifying it to be blocked
• Signal set: set of signals
• Signal mask: the set of signals that are currently blocked
• int sigprocmask (int how, const sigset_t *restrict set, sigset_t *restrict oldset)
• Operations:
• sigaddset(): Add a signal to the set
• sigdelset(): Remove a signal from the set
• sigismember(): Check if a signal is in the set
• sigemptyset(): Clear all signals in the set
• sigfillset(): Initialize and fill a set with all supported signals
Difference between blocking & ignoring
• Blocking
• The operating system does not deliver the signal until the process unblocks the signal
• A process blocks a signal with sigprocmask. • Ignoring
• When a process ignores a signal, the signal is delivered and the process handles it by throwing it away
• A process ignores a signal by calling sigaction • By specifying the signal handler to SIG_IGN
Manipulating Signal Masks
int sigprocmask(int how, sigset_t *set, sigset_t *old_set);
• Manipulates the signal mask (set of blocked signals) • Parameters
• how: How the signal mask would be modified
• SIG_BLOCK: Add a set of signals for blocking
• SIG_UNBLOCK: Unblock a set of signals
• SIG_SETMASK: Set current signal mask to given signal set
• set: Signal set to be used for manipulation
• old_set: The old signal mask before modification
sigset_t newsigset, oldsigset;
/* Add SIGINT to the new signal set */
sigemptyset(&newsigset);
sigaddset(&newsigset, SIGINT);
/* Add SIGINT to the set of blocked signals */ sigprocmask(SIG_BLOCK, &newsigset, &oldsigset);
/* Check if SIGQUIT is in the new signal mask */
if (sigismember(&newsigset, SIGQUIT)) printf(“SIGQUIT already blocked\n”);
else if (sigismember(&newsigset, SIGINT)) printf(“SIGINT already blocked\n”);
In this example, Control+C cannot terminate it
Catching & Handling Signals
Catching Signals
• Signals have default handlers
• But user may want to take meaningful actions for specific events.
• Example: saving data before quitting
• A singal handler function is defined for that purpose • It is called upon signal delivery
void (*sa_handler)(int)
Argument is set to the signal number being delivered.
sigaction() function
int sigaction(int sig, struct sigaction *action, struct sigaction *old_action);
• Allows the caller to examine or specify the action associated with a specific signal • Parameters
• sig: Name of the signal
• action: Action to be taken
• old_action: The previous action associated with the signal
struct sigaction
• struct sigaction:
• sa_handler: Signal handler
• sa_mask: Additional signals to be blocked in the signal handler • sa_flags: Special flags and options
• sa_sigaction: Realtime signal handler
• Only one of sa_handler and sa_sigaction can be specified
• Use sa_handler for default and use sa_sigaction for realtime signals
void myhandler(int signo) {
printf(“Received signal: %d\n”, signo);
struct sigaction newact;
newact.sa_handler = myhandler; /* Set sig handler */ sigemptyset(&newact.sa_mask); /* No other signals to be blocked */ newact.sa_flags = 0; /* No special options */
/* Install the signal handler for SIGINT */
sigaction(SIGINT, &newact, NULL);
Waiting for Signals
Waiting for Signals
• Sometimes a process needs to wait until an event occurs.
• E.g., driven by external events, or uses signals for synchronization
• Naive approach: busy waiting which wastes CPU cycles
• A more efficient approach is to use Signals
• Suspend the process until the waited-for event occurs.
• Approach 1: Set a signal handler for a specific signal and wait until the signal is caught
• sigsuspend
• Approach 2: Block a signal and wait for signal to be generated
int pause(void)
• Suspends the calling thread until the delivery of a signal
• Returns after the signal handler returns
• Have to check which signal arrived
• Major problem: signal can be delivered before calling pause
• If no further signals arrive, the process would never wake up again. • Would like to:
• Block the desired signal until pause
• Unblock the signal and start pause at once • Pause is made obsolete by sigsuspend
sigsuspend()
int sigsuspend(const sigset_t *sigmask);
• Atomically release blocked signals and wait for interrupt • Temporarily changes signal mask
• Operations done atomically
• Signals in sigmask are blocked
• Signal mask used to atomically unblock the signal to be caught • Remove desired signal from the signal mask
int sigwait(const sigset_t *restrict sigmask, int *restrict signo);
• Blocks until any of the signals in the sigmask is pending or generated
• Removes that signal from the set of pending signals and unblocks
• When sigwait returns, the number of the signal that was removed from the pending
signals is stored in the location pointed to by signo.
• The signals specified by set should be blocked, but not ignored
• Otherwise: wait indefinitely
Difference between sigwait and sigsuspend
Both functions have a first parameter that is a pointer to a signal set (sigset_t *)
• For sigsuspend:
• this set holds the new signal mask and so the signals that are not in the set
are the ones that can cause sigsuspend to return • For sigwait:
• this parameter holds the set of signals to be waited for (an opposite way!), so the signals in the set are the ones that can cause the sigwait to return
• the signals in sigmask should be blocked before sigwait is called
• Unlike sigsuspend, sigwait does not change the process signal mask
Signal Safety – To avoid race conditions
• Signals are asynchronous: can arrive in the middle of a function
• Some library functions are not async-signal safe
• Some blocking calls return prematurely when interrupted by signals, e.g., read,
write, etc. Ensuring Signal Safety:
• May need to restart interrupted library calls
• Use async-signal safe library calls inside signal handlers
• Block a signal before entering critical sections that may conflict with the
signal handler
• Save and restore errno inside the signal handler
Realtime Signals
Realtime Signals
• Limitation with original signals
• By default, when multiple signals are blocked, only one pending signal is delivered
• So we lose multiple signals—signals of the same number are merged
• Cannot pass data along wth the signals
• Realtime signals allow queuing of signals with order guaranteed • Also allow passing data with the signal
• Large number of new user defined signals
• SIGRTMIN…SIGRTMAX • Ordering of signal delivery
• Queued signals in FIFO order
• Priority order between RT signals
• Lower number signals are given priority over higher number signals
Using Realtime Signals
• Can enqueue multiple instances of the same signal type • Can send data with the signal
• Can send different RT signals with different priority
• Receiver:
• Can pick up one signal instance at a time
• Can pick up data: catch signals using a different signal handler, or different
signal waiting call
Queuing Signals
int sigqueue(pid_t pid, int signo, union sigval value);
• Queues a signal to another process • Also sends data with the signal
• Parameters
• pid: Signal-receiving process
• Sender should have appropriate permissions
• signo: Signal number
• value: Data passed with the signal • Union of int and (void *)
union sigval
union sigval {
int sival_int; void *sival_ptr;
A small amount of data to pass
/* Data passed with notification */
/* Integer value */
/* Pointer value */
Specifying Alternative Signal Handler
struct sigaction {
void (*sa_handler)(int); /* SIG_DFL, SIG_IGN, or pointer to function */ /* additional signals to be blocked during execution of handler */ sigset_t sa_mask;
int sa_flags; /* special flags and options */
void(*sa_sigaction) (int, siginfo_t *, void *); /* realtime handler */
• For realtime behavior:
• sa_flags should be set to SA_SIGINFO
• sa_sigaction should be set to the handler
Realtime Signal Handler
void func(int signo, siginfo_t *info, void *context)
• Parameters:
• signo: Signal number
• info: Contains information about signal data • context: Undefined
struct siginfo_t
typedef struct { int si_signo;
int si_code;
union sigval si_value; …
} siginfo_t;
• si_signo: Signal number (same as signo) • si_code: How signal was generated
• By a user process using kill
• Using sigqueue
• Timer, asynchronous I/O, etc.
• si_value: Data generated with the signal • Union of int and (void *)
Example: Sender
union sigval value;
/* Set value to send with signal */
value.sival_int = 1;
/* Send signal to be queued */
sigqueue(pid, SIGRTMIN, value);
Example: Receiver
/* Signal handler */
void myhandler(int signo, siginfo_t *info, void *context) {
int val = info->si_value.sival_int;
printf(“Signal: %d, value: %d\n”, signo, val);
struct sigaction act;
act.sa_sigaction = myhandler; /* Set RT sig handler */ sigemptyset(&act.sa_mask);
act.sa_flags = SA_SIGINFO; /* RT sigs flag */
/* Install the signal handler for SIGRTMIN */
sigaction(SIGRTMIN, &act, NULL);
Waiting for RT Signals: sigwaitinfo()
int sigwaitinfo(sigset_t *set, siginfo_t *info);
• Similar to sigwait
• Returns when one of the signals becomes pending • Removes it from set of pending signals
• Parameters
• set: Set of signals to wait for
• info: Contains info about signal data
Realtime Signals Usage
• Two advantages: queuing signals and carrying values
• Lightweight IPC: Processes can pass int or pointer values • Timer interrupts could be sent more efficiently
• Multiple timer interrupts could be queued
• I/O multiplexing easier
• File descriptors could be sent with I/O ready signals
• Asynchronous I/O could be signaled easily
• Data pointer could be returned with the signal
• Is it possible to block only a few signals of your choice?
1. Yes 2. No
Quiz 1 Ans
• Ans: Yes. You can mask the signals of your choice.
• Will signals affect the thread-safety of a process?
1. Yes 2. No
Quiz 2 Ans
• Will signals affect the thread-safety of a process?
• Ans: Yes. Reference: Slide Signal Safety – To avoid race conditions.
• Which of the following is/are true about realtime signals?
1. It is queued in LIFO order
2. We can enqueue many signals that will be delivered, even multiple instances
of the same signal
3. We can pass data with the notifications
4. It is thread-safe
Quiz 5 Ans
• Which of the following is/are true about realtime signals?
1. It is queued in LIFO order
2. We can enqueue many signals that will all be delivered, even multiple
instances of the same signal
3. We can pass data with the notifications
4. It is thread-safe
• Ans: 2 and 3.
Next lecture
• Networking (remote communication)
Student Rating of Teaching is open, please provide your feedback! !
References
• Robbins 8.1-8.5
• Robbins 9.4
• http://www-users.cselabs.umn.edu/classes/Spring-
2018/csci4061/notes/signals.pdf
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com