outline for today objectives –finish discussion of birrell –unix signals –eraser...
TRANSCRIPT
Outline for Today
• Objectives– Finish discussion of Birrell– UNIX Signals– Eraser
• Administrative– Spider talk after class
AlertsThread state contains flag, alert-pending
Exception alerted
Alert (thread)alert-pending to true, wakeup a
waiting thread
AlertWait (mutex, condition)if alert-pending set to false and raise
exception
else wait as usual
Boolean b = TestAlert()tests and clear alert-pending
TRYwhile (empty) AlertWait (m, nonempty); return (nextchar());
EXCEPTThread.Alerted:
return (eof);
Using Alerts
sibling = Fork (proc, arg);
while (!done)
{ done = longComp();
if (done) Alert (sibling);
else done = TestAlert();
}
Wisdom
Do s• Reserve using alerts for
when you don’t know what is going on
• Only use if you forked the thread
• Impose an ordering on lock acquisition
• Write down invariants that should be true when locks aren’t being held
Don’t s• Call into a different
abstraction level while holding a lock
• Move the “last” signal beyond scope of Lock
• Acquire lock, fork, and let child release lock
• Expect priority inheritance since few implementations
• Pack data and expect fine grain locking to work
Signals• Signals notify processes of internal or external events.
– the Unix software equivalent of interrupts/exceptions– only way to do something to a process “from the outside”– Unix systems define a small set of signal types
• Examples of signal generation:– keyboard ctrl-c and ctrl-z signal the foreground process– synchronous fault notifications, syscall errors – asynchronous notifications from other processes via kill– IPC events (SIGPIPE, SIGCHLD)– alarm notifications
signal == “upcall”
Process Handling of Signals
1. Each signal type has a system-defined default action.abort and dump core (SIGSEGV, SIGBUS, etc.)ignore, stop, exit, continue
2. A process may choose to block (inhibit) or ignore some signal types.
3. The process may choose to catch some signal types by specifying a (user mode) handler procedure.
specify alternate signal stack for handler to run onsystem passes interrupted context to handlerhandler may munge and/or return to interrupted context
Using Signals
int alarmflag=0;
alarmHandler ()
{ printf(“An alarm clock signal was received\n”);
alarmflag = 1;
}
main()
{
signal (SIGALRM, alarmHandler);
alarm(3); printf(“Alarm has been set\n”);
while (!alarmflag) pause ();
printf(“Back from alarm signal handler\n”);
}
Suspends calleruntil signal
Instructs kernel to send SIGALRM in3 secondsSets up signal handler
Yet Another User’s Viewmain(argc, argv)
int argc; char* argv[];{
int pid;
signal (SIGCHLD,childhandler);
pid = fork ();
if (pid == 0) /*child*/
{ execvp (argv[2], &argv[2]); }
else
{sleep (5);
printf(“child too slow\n”);
kill (pid, SIGINT);}
}
childhandler()
{ int childPid, childStatus;
childPid = wait (&childStatus);
printf(“child done in time\n”);
exit;
}
SIGCHLD sentby child on termination;if SIG_IGN, dezombie
Collects status
When to Deliver Signals?
runuser
runkernel
readyblocked
run
wakeup
trap/fault
sleep
preempted
suspend/run
new
fork
zombie exit
swapout/swapin swapout/swapin
(suspend)
Interrupt low-priority sleep if signal is posted.
Check for postedsignals after wakeup.
Deliver signals when resuming to user mode.
Deliver signals when returning to user mode from trap/fault.