Download Process Interactions - Operating Systems - Lecture Notes and more Study notes Operating Systems in PDF only on Docsity!
Deadlocks : an operation cannot complete because two entities are waiting for each other (circular wait). So far, we've talked about one kind of process interaction: Atomicity : freedom from interaction; part of a process proceeds alone. Race conditions : result of an operation depends upon timing between process and events in outside world. Race conditions can affect non-atomic operations. Processes interact in a number of other ways with their environment: Process interactions Monday, September 25, 2006 4:52 PM Docsity.com
Race conditions Deadlocks Too little control Too much control Concurrency can create state botches Concurrency can't happen Race conditions and deadlocks are opposites Thursday, October 04, 2012 1:43 PM Docsity.com
Can be logically atomic, in which case all is well. Can fail to be logically atomic, and become a risk. critical section : a piece of code that should be logically atomic ; it should execute without interruption by outside forces. Race condition vocabulary Race condition language Thursday, October 04, 2012 1:50 PM Docsity.com
An individual machine instruction is atomic at the machine level; it can't be executed halfway. E.g., calls to write are atomic. Other kinds of atomicity arise from disabling the scheduler , e.g., during system calls. E.g., by modifying the signal mask. A third kind of atomicity arises from disabling signals. And a fourth kind arises from using advisory locking, e.g., arbitrating access to critical sections via some outside programmatic mechanism. Kinds of atomicity Kinds of atomicity Thursday, October 04, 2012 1:36 PM Docsity.com
http://www.cs.tufts.edu/comp/111/examples/Process_Interacti on/sigrace2.c Which one is ok? Which one is dangerous? Docsity.com
Why one example crashes and the other can't head=p; is logically atomic ; it's compiled into one machine instruction. Thus calling many stacked instances of link_at_head(int) at the same time will not cause problems. (but might lose data). The line if(head) { struct element *p=head; int ret = p->counter; head=head->next; free(p); return ret; } This is not logically atomic. This is called once and interrupted after the if and before head=head->next, and then called again during the interruption, head will be NULL when the last head=head-> next is called. Result: segmentation fault. The critical section of unlink_from_head() is the whole section: The problem is that if(head) makes a decision Why one crashes and the other can't Thursday, October 04, 2012 2:55 PM Docsity.com
E.g., removing from a linked list. Some process actions should not be interrupted in the middle So we need to make such linking "atomic". Signals have the ability to interrupt such things. Then protected operations are atomic, i.e., they cannot be interrupted by signals. Solution: signal blocking. Signal blocking Thursday, September 30, 2010 Docsity.com
○ sigprocmask sets the signal mask. ○ Signal mask : list of signals not to handle. ○ An array of integers. ○ Use 'man sigsetops' operators to set it Blocking signals Example: // int sigprocmask(int how, // const sigset_t *set, // sigset_t *oldset); sigset_t mask; sigset_t oldmask; sigemptyset(&mask); sigaddset(&mask, SIGINT); &mask, &oldmask); int ret = sigprocmask(SIG_BLOCK, // now SIGINT is blocked // (ignore control-C) fprintf(stderr, "betcha can't control-C me!\n"); sleep(5); // unblock the mask &mask, &oldmask); ret = sigprocmask(SIG_UNBLOCK, // now control-C works again. Blocking signals Tuesday, September 21, 2004 11:05 AM Docsity.com
const struct sigaction *act, struct sigaction oldact); int sigaction(int signum, POSIX sigaction call: void (handler)(int); void ); void (sigaction)(int, siginfo_t *, union { } __sigaction_handler; sigset_t sa_mask; // mask to set WHEN an signal received. int sa_flags; struct sigaction { }; __sigaction_handler.handler #define handler
__sigaction_handler.sigaction #define sigaction
Now we really have to work: Prefix rule for subroutine calls: if one subroutine has an argument list that's a prefix of another, then EITHER may be called with the LONG argument list. sigaction Monday, September 20, 2004 4:43 PM Docsity.com
Assuring atomicity of a signal handler: signal(SIG, handler) // here, another signal might happen! sigprocmask(SIG_BLOCK,...); /... do work .../ sigprocmask(SIG_UNBLOCK,...); void handler(int s) { } There is a special signal stack that is separate from the process's stack… Signals can stack. Approach #1: set mask in sigaction call. Approach #2: There is no race condition. Signals are blocked in the kernel, before invoking the handler. #2 is inherently better! Assuring atomicity Monday, September 20, 2004 4:43 PM Docsity.com
signal handlers are never called until the block mask is instantiated.
signal blocking is done in the kernel, not the application.
Thus there is no way for signals to stack inappropriately in a sigaction environment.
Key to sigaction: Key to sigaction Monday, September 20, 2004 4:43 PM Docsity.com
sa_handler, sa_sigaction: pointers to handler functions of differing types. These are a (hidden, slimy) union! Do not assign to both! sa_mask: set of signals to be automatically blocked before calling a handler. sa_flags: various options. Parts of struct sigaction: struct sigaction Monday, September 20, 2004 4:43 PM Docsity.com
any condition in which the result of a process depends upon the timing between the process and its environment. common race conditions: I/o, concurrency. Race condition a parent and child share a pipe. the parent writes to the pipe. then both parent and child try to read the same pipe. result: first one that gets there wins; other one loses! A typical race condition: Race conditions Monday, September 25, 2006 4:54 PM Docsity.com
A signal causes a list to be updated from a file. E.g., SIGHUP. Meanwhile, the program may in fact be updating the list itself, e.g., adding an element. Depending upon when the update occurs, the list in memory will differ! A very bad race condition: "Heisenbugs": observing them changes behavior. A "POM" condition: depends upon the "phase of the moon" Race conditions can vary so infrequently that they seem non-deterministic. Subtle: A very bad race condition Monday, September 25, 2006 4:54 PM Docsity.com
