Upload
klaus
View
50
Download
4
Embed Size (px)
DESCRIPTION
Chapter 6 Processes and Operating Systems. 金仲達教授 清華大學資訊工程學系 (Slides are taken from the textbook slides). Overview. Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machine. - PowerPoint PPT Presentation
Citation preview
Chapter 6
Processes and Operating Systems
金仲達教授清華大學資訊工程學系
(Slides are taken from the textbook slides)
Operating Systems-2
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-3
Introduction When multiple operations must be performed
at widely varying times, a single program can easily become too complex
Two abstractions to build complex applications: process: defines the state of an executing program
=> compartmentalize functions operating system: provides mechanism for
switching execution between the processes=> encapsulate control for switching processes
Allowing switching state of processor between multiple tasks building applications with more complex
functionality and greater flexibility to satisfy timing requirements
Operating Systems-4
Why multiple processes? Need to structure programs to perform multip
le tasks Processes help us manage timing complexity:
receive and send data at multiple rates, e.g., multimedia, automotive
asynchronous input, e.g., user interfaces, communication systems
Multirate systems make meeting timing requirements even more complex: certain operations must be executed periodically ,
and each is executed at its own rate
Operating Systems-5
Example: engine control Tasks:
spark control crankshaft sensing fuel/air mixture oxygen sensor Kalman filter
To fire spark plugperiodically, setthrottle, adjustfuel/air mixture, etc.
enginecontroller
Operating Systems-6
Life without processes Code turns into a mess:
interruptions of onetask for another
spaghetti codetime A
B
C
A
C
A_code();…B_code();…if (C) C_code();…A_code();…switch (x) { case C: C(); case D: D(); ...
Operating Systems-7
Early multitasking: co-routines
ADR r14,co2aco1a …
ADR r13,co1bMOV r15,r14
co1b …ADR r13,co1cMOV r15,r14
co1c ...
co2a …ADR r14,co2bMOV r15,r13
co2b …ADR r14,co2cMOV r15,r13
co2c …
Co-routine 1 Co-routine 2
r13: holds return address for co-routine 1r14: holds return address for co-routine 2
Operating Systems-8
Co-routine methodology A co-routine has several different entry
points give hooks for nonhierarchical calls and returns
Like subroutine, but caller determines the return address
Co-routines voluntarily give up control to other co-routines
Pattern of control transfers is embedded in the code => difficult to handle timing requirements
Operating Systems-9
Processes A process is a unique execution of a
program. A process is defined by its code and data Several copies of a program may run
simultaneously or at different times A process has its own state:
registers memory
The operating system manages processes
Operating Systems-10
Processes and CPUs Activation record: copy of process state Context switch:
current CPU contextgoes out
new CPU contextgoes in
CPU
PC
registers
process 1
process 2
...
memory
Operating Systems-11
Terms Thread = lightweight process: a process
that shares memory space with other processes avoid the cost and complexity of memory
management units that provide strict separation between memory spaces
Reentrancy: ability of a program to be executed several times with the same results.
Operating Systems-12
Processes in POSIX Create a process with fork():
Two processes are exactly the same in code and data, except the return value of fork()
process a
process a(parent)
process a(child)
Operating Systems-13
fork() The fork system call creates a child process:
childid = fork();if (childid == 0) {/* child operations */
} else {/* childid = child proc id *//* parent operations */
}
Operating Systems-14
execv() Overlays child code:
childid = fork();if (childid == 0) {execv(“mychild”,childargs);perror(“execv”);exit(1);
}file with child code
Operating Systems-15
wait() Parent waits for the child to terminate and rel
ease all resources:
childid = fork();if (childid == 0) {/* child things */
} else { /* parent things */ wait(&cstatus); exit(0);}
Operating Systems-16
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-17
Context switching Moving CPU from one executing process to
another Bug-free: process not know it was stopped fast
Who controls when the context is switched?
How is the context switched?
Operating Systems-18
Co-operative multitasking A restricted form of context switches One process gives up CPU to another voluntari
ly Improvement on co-routines:
hides context switching mechanism; still relies on processes to give up CPU.
Each process allows a context switch by calling cswitch()
A scheduler chooses which process runs next
Operating Systems-19
Cooperative multitasking processesIf (x>2) sub1(y);else sub2(y,z);cswitch();proca(a,b,c);
Process 1
proc_data(r,s,t);cswitch();if (val1==3) abc(val2);
Process 2
save_state(current);p=choose_process();load_and_go(p);
Scheduler
Operating Systems-20
Context switching in ARM
r13
CPU
Memory
currentprocesscontextblock
CPSR
PC
r0
r14
Save and restore process contexts
Operating Systems-21
Cooperative context switching in ARM Save old process:
STMIA r13,{r0-r14}^MRS r0,SPSRSTMDB r13,{r0,r15}
Start new process:
ADR r0,NEXTPROCLDR r13,[r0]LDMDB r13,{r0,r14}MSR SPSR,r0LDMIA r13,{r0-r14}^MOVS pc,r14
STMIA r13,{r0-r14}^: store all registers to memory pointed by r13MRS r0,SPSR: save content of SPSR to r0STMDB r13,{r0,r15}: save SPSR and PC to memory pointed by r13NEXTPROC: variable pointing to next process’s context block
Operating Systems-22
Problems with co-operative multitasking Programming errors can keep other
processes out, because the CPU must be voluntarily given up by a process process never gives up CPU process waits too long to switch, missing input
process2() { x = global1; /* input to process */ while (x<500) x = aproc(global2); switch();} x may always <500 and
process never switch
Operating Systems-23
Preemptive multitasking Most powerful form of multitasking:
OS controls when contexts switches OS determines what process runs next Take advantage of interrupt mechanism
Use timer to interrupt OS, switch contexts Reduce consequence of programming errors Allocate CPU time more efficiently
CPU tim
er
interrupt
Operating Systems-24
Preemptive context switching Timer interrupt gives control to OS, which
saves interrupted process’s state in activation record
OS chooses next process to run. OS installs desired activation record as
current CPU state.
time
P1 OS P1 OS P2
interrupt interrupt
Operating Systems-25
Processes and UML A process is an active class, independent
thread of control Signal: object that is passed between
processes for active communication
processClass1
myOperations()
startresume
myAttributes
Signals
acomm: datasignal
Operating Systems-26
Designing with active objects Can mix normal and active objects:
p1: processClass1
master: masterClass
w: wrapperClass
a: rawMsg
ahat: fullMsg
Operating Systems-27
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-28
Operating systems The operating system controls resources:
who gets the CPU when I/O takes place how much memory is allocated
The most important resource is the CPU itself CPU access controlled by the scheduler
OS simplifies the control code required to coordinate processes scheduling is centralized
Operating Systems-29
Process state A process can be in one of three states:
executing on the CPU ready to run waiting for data
Use process priorities tochoose next executingprocess
executing
ready waiting
gets dataand CPU
needsdata
gets data
needs data
preemptedgetsCPU
Operating Systems-30
Priority-driven scheduling Each process has a priority. CPU goes to highest-priority process that
is ready. Priorities determine scheduling policy:
fixed priority; time-varying priorities.
Operating Systems-31
Priority-driven scheduling example Rules:
each process has a fixed priority (1 highest); highest-priority ready process gets CPU; process continues until done.
Processes P1: priority 1, execution time 10 P2: priority 2, execution time 30 P3: priority 3, execution time 20
Operating Systems-32
Priority-driven scheduling example
time
P2 ready t=0 P1 ready t=15interrupt P2
P3 ready t=18
0 3010 20 6040 50
P2 P2P1 P3
Operating Systems-33
Operating system structure OS needs to keep track of:
process priorities; scheduling state; process activation record.
Processes may be created: statically before system starts; dynamically during execution (process state record
s kept in a linked list) When some events occur aperiodically and infr
equently, it is reasonable to create a process to handle the event when it occurs
Operating Systems-34
Operating system structure OS generally executes in the protected
mode ARM uses SWI (software interrupt) to
provide OS access Puts CPU into the supervisor mode Exception vector table directs execution to the
proper place in OS The one argument passes a parameter to the
OS
Operating Systems-35
Process timing requirements Process initiation disciplines:
Periodic process: executes on (almost) every period. Aperiodic process: executes on demand.
Analyzing aperiodic process sets is harder---must consider worst-case combinations of process activations.
Operating Systems-36
Timing requirements on processes Period: interval between process
activations. Rate requirement: how quickly processes
must be initiated Inverse gives the initiation interval
Initiation time: time at which process goes from waiting to ready.
Deadline: time at which process must finish.
Operating Systems-37
Timing requirements
timeP1
Initiating event
DeadlineAperiodicprocess
timeP1
DeadlinePeriodicprocess(initiatedat periodstart)
Period
timeP1
DeadlinePeriodicprocess
PeriodInitiating event
Operating Systems-38
Timing violations What happens if a process doesn’t finish
by its deadline? Hard deadline: system fails if missed. Soft deadline: user may notice, but system
doesn’t necessarily fail.
Operating Systems-39
Example: Space Shuttle software error Space Shuttle’s first launch was delayed
by a software timing error: Primary control system PASS and backup
system BFS. BFS failed to synchronize with PASS. Change to one routine added delay that threw
off start time calculation. 1 in 67 chance of timing problem.
Operating Systems-40
Interprocess communication Interprocess communication (IPC): OS provide
s mechanisms so that processes can pass data. Two types of semantics:
blocking: sending process waits for response; non-blocking: sending process continues.
Operating Systems-41
IPC styles Shared memory:
processes have some memory in common; must cooperate to avoid destroying/missing
messages. Message passing:
processes send messages along a communication channel---no common address space
They are logically equivalent
Operating Systems-42
Shared memory Shared memory on a bus:
Need a flag to tell one CPU when the data from the other CPU is ready
Uni-directional flag: easy with a memory write Problem with bi-directional flag
CPU 1 CPU 2memory
Operating Systems-43
Race condition in shared memory Problem when two CPUs try to write the
same location: CPU 1 reads flag and sees 0. CPU 2 reads flag and sees 0. CPU 1 sets flag to one and writes location. CPU 2 sets flag to one and overwrites location.
Operating Systems-44
Atomic test-and-set Problem can be solved with an atomic test-an
d-set over the bus: single bus operation reads memory location, tests i
t, writes it. ARM test-and-set provided by SWP Rd,Rm,Rn:
Memory pointed by Rn is loaded into Rd and Rm is written to Rn
ADR r0,SEMAPHORE LDR r1,#1GETFLAG SWP r1,r1,[r0] BNZ GETFLAG
Operating Systems-45
Critical regions Critical region: section of code that cannot
be interrupted by another process. Examples: writing shared memory, accessing
I/O device Controlling access to critical region using
semaphores: Get access to semaphore with P() Perform critical region operations Release semaphore with V()
P() and V() can be implemented with test-and-set
Operating Systems-46
Message passing Message passing on a network:
Messages stored at endpoints, not comm link Good for applications with autonomic components,
specially for those operate at different rates
CPU 1 CPU 2Message
boxMessage
Box
message
Operating Systems-47
Process data dependencies Express relationships of processes running
at the same rate One process may not be able
to start until dependingones finish
Dependencies form a partialordering of process execution
Data dependencies defined ina directed acyclic graph, task graph
P1 P2
P3
P4
Operating Systems-48
Other operating system functions The role of OS may be viewed as
managing shared resources Date/time File system: for organizing large data sets,
even without hard disks Networking Security Debugging facility
Operating Systems-49
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-50
Embedded vs. general-purpose scheduling Workstations try to avoid starving
processes of CPU access. Fairness = access to CPU.
Embedded systems must meet deadlines. Low-priority processes may not run for a long
time
Operating Systems-51
The scheduling problem Scheduling policy: defines how processes
are selected for promotion from ready to running
Can we meet all deadlines? Must be able to meet deadlines in all cases.
How much CPU horsepower do we need to meet our deadlines?
Operating Systems-52
Metrics How do we evaluate a scheduling policy:
Ability to satisfy all deadlines. CPU utilization: percentage of time devoted to
useful work Scheduling overhead: time required to make
scheduling decision
Operating Systems-53
POSIX for real-time scheduling Defined in _POSIX_PRIORITY_SCHEDULING Use sched_setschedule() to change scheduling:
#includ <sched.h>int i, my_process_id;struct sched_param my_sched_params;…i = sched_setschedule(my_process_id,
SCHED_FIFO, &my_sched_params);
Operating Systems-54
Priority-Driven Algorithm Fixed priority algorithm
Assigns the same priority to all the jobs in each task
Example: RM (Rate-Monotonic), DM(Deadline-Monotonic)
Dynamic priority algorithm Assigns different priorities to the individual jobs
in each task Example: EDF (Earliest Deadline First)
Operating Systems-55
Rate monotonic scheduling RMS [Liu and Layland, 73]: widely-used, analyz
able scheduling policy Analysis is called Rate Monotonic Analysis (RM
A) Assumptions:
All processes run periodically on single CPU. Zero context switch time. No data dependencies between processes. Process execution time is constant. Deadline is at end of respective period. Highest-priority ready process runs.
Operating Systems-56
RMS priorities Optimal (fixed) priority assignment:
shortest-period process gets highest priority; priority inversely proportional to period; break ties arbitrarily.
No fixed-priority scheme does better In terms of CPU utilization while ensuring all
processes meet their deadlines
Operating Systems-57
RMS exampleProcess Execution time PeriodP1 1 4P2 2 6P3 3
12
time
0 62 4 128 10
P1
P2
P3
P1 P1
P2
P3 P3
Operating Systems-58
Examples of RM schedules A RM schedule of T1=(2,0.9) and
T2=(5,2.3) T1:Utilizations=0.9/2=0.45 T2:Utilizations=2.3/5=0.46
10
T2
5
2 4 6 8
T1
Operating Systems-59
RMS exampleProcess Execution time PeriodP1 2 4P2 3 6P3 3
12
No feasible assignment of priorities to satisfy deadlines:In 12 unit intervals, execute P1 3 times, P2 2 times, P3 1 times => (6+6+3)=15 unit intervals
Operating Systems-60
Process parameters Ti is computation time of process i; i is period
of process i.
period i
Pi
computation time Ti
Operating Systems-61
RMS CPU utilization Utilization for n processes is
i Ti / i Maximum utilization: n (21/n -1)
As number of tasks approaches infinity, maximum utilization approaches 69% RMS cannot use 100% of CPU, even with zero conte
xt switch overhead. Must keep idle cycles available to handle worst-cas
e scenario. However, RMS guarantees all processes will always
meet their deadlines.
Operating Systems-62
RMS example
time
0 5 10
P2 period
P1 period
P1
P2
P1 P1
P1: period 4, execution time 2 P2: period 12, execution time 1 CPU utilization = (2 x 3 + 1)/12 = 0.5833
Operating Systems-63
Rate-monotonic analysis Response time: time
to finish process Critical instant:
scheduling state thatgives worst responsetime. occurs when all higher-
priority processes areready to execute.
P4
P3
P2
P1
criticalinstant
P1 P1 P1 P1
P2 P2
P3
interfering processes
Operating Systems-64
RMS implementation Efficient implementation:
scan processes choose highest-priority active process
POSIX: SCHED_FIFO for RMS
int i, mypid;struct_sched_param my_param;mypid = getpid();i = sched_getparam(mypid, &my_params);my_params.sched_priority = maxval;i = sched_setparam(mypid, &my_params);
Operating Systems-65
Earliest-deadline-first scheduling EDF: dynamic priority scheduling scheme. Process closest to its deadline has highest
priority. Requires recalculating processes at every
timer interrupt.
Operating Systems-66
Example of the EDF Algorithm T1=(2,0.9) and T2=(5,2.3)
10
T2
5
2 4 6 8
T1
J1.1 is 2 , J2.1 is 5
Priority:J1.1>J2.1
J1.2 is 4 , J2.1 is 5
Priority:J1.2>J2.1
J1.2 preempts J2.1
J1.3 is 6 , J2.1 is 5
Priority:J2.1>J1.3
At time 4.1,J2.1 completes , J1.3 start to execute
Operating Systems-67
EDF analysis EDF can use 100% of CPU. Scheduling cost is high and ready queue
can reassign priority. But EDF may fail to meet a deadline. Cannot guarantee who will miss deadline,
RM can guarantee the lowest priority task miss deadline.
Operating Systems-68
EDF implementation On each timer interrupt:
compute time to deadline; choose process closest to deadline.
Generally considered too expensive to use in practice.
Operating Systems-69
Fixing scheduling problems What if your set of processes is unschedulable?
Change deadlines in requirements. Reduce execution times of processes. Get a faster CPU.
Can we relax the assumptions?
Operating Systems-70
Assumption on process self-contain Priority inversion: low-priority process
keeps high-priority process from running if we do not consider resources Low-priority process grabs I/O device. High-priority device needs I/O device, but can’t
get it until low-priority process is done. Can cause deadlock Solution:
Give priorities to system resources. Process inherit priority of a resource that it
requests. Low-priority process inherits priority of device if
higher
Operating Systems-71
Assumption on data independence Data dependencies allow us to improve
utilization Restrict combination of processes that can run
simultaneously. E.g., P1 and P2 can’t run simultaneously.
P1
P2
Operating Systems-72
Assumption on context switch time Non-zero context switch time can push
limits of a tight schedule. Hard to calculate effects---depends on
order of context switches. In practice, OS context switch overhead is
small.
Operating Systems-73
POSIX scheduling policies SCHED_FIFO: RMS SCHED_RR: round-robin
within a priority level, processes are time-sliced in round-robin fashion
SCHED_OTHER: undefined scheduling policy used to mix non-real-time and real-time processes.
Operating Systems-74
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-75
Signals A Unix mechanism for simple
communication between processes. Analogous to an interrupt---forces
execution of a process at a given location. But a signal is caused by one process with a
function call. No data---can only pass type of signal.
Operating Systems-76
POSIX signals Must declare a signal handler for the process u
sing sigaction(). Handler is called when signal is received. A signal can be sent with sigqueue():
sigqueue(destpid,SIGRTMAX-1,sval)
Operating Systems-77
POSIX signal types SIGABRT: abort SIGTERM: terminate process SIGFPE: floating point exception SIGILL: illegal instruction SIGKILL: unavoidable process termination SIGUSR1, SIGUSR2: user defined
Operating Systems-78
Signal example/* define handler for SIGUSR1 */#include <signal.h>extern void usr1_handler(int); /* SIGUSR1 */struct sigaction act,oldact;int retval;/* set up the descriptor data structure */act.sa_flags=0;sigemtyset(&act.sa_mask); /* initialize */act.sa_handler=usr1_hanler; /*add handler*//* tell OS about the handler */relval=sigaction(SIGUSR1,&act,&oldact);
Operating Systems-79
POSIX shared memory POSIX supports counting semaphores with _P
OSIX_SEMAPHORES option. Semaphore with N resources will not block until N
processes hold the semaphore. Semaphores are given name, e.g., /sem1int i, oflags;sem_t *my_semaphore; /* descriptor */
my_semaphore = sem_open(“/sem1”,oflags);/* do useful work here */i = sem_close(my_semaphore);
Operating Systems-80
POSIX counting semphores P() is sem_wait(), V() is sem_post()int i;i = sem_wait(my_semaphore); /* P *//* do useful work */i = sem_post(my_semaphore); /* V *//* sem_trywait tests without blocking */i = sem_trywait(my_semaphore);
Operating Systems-81
POSIX shared memory POSIX shared memory is supported under _POS
IX_SHARED_MEMORY_OBJECT
Use shm_open() to open a shared object:objdesc = shm_open(“/memobj1”,O_RDWR);/*return origin of shared memory in disk*/
Map shared memory object into process memoryif(mmap(addr,len,O_RDWR,MAP_SHARED,
objdesc,0) == NULL) { /* error */ }/*MAP_SHARED propagate all writes to all sharing processes */
Operating Systems-82
POSIX message-based communication Unix pipe supports messages between process
es. % foo files | baz > file2
Parent process uses pipe() to create a pipe. Pipe is created before child is created so that pipe I
D can be passed to child. An alternative is message queues under _POSI
X_MESSAGE_PASSING
Operating Systems-83
POSIX pipe example/* create the pipe */if (pipe(pipe_ends) < 0) { perror(“pipe”); break; }/* create the process */childid = fork();if (childid == 0) {/*child reads from pipe_ends[1]*/
childargs[0] = pipe_ends[1];execv(“mychild”,childargs);perror(“execv”);exit(1);
}else { /* parent writes to pipe_ends[0] */ … }
Operating Systems-84
POSIX message queue examplestruct mq_attr mq_attr; /*attributes of the queue */mqd_t myq; /*queue descriptor */
mq_attr.mq_maxmsg = 50; /* max number of messages */mq_attr.mq_msgsize = 64; /* max size of a message */mq_attr.mq_flags = 0;myq= mq_open(“/q1”,O_CREATE|RDWR,S_IRWXU,&mq_attr);….
/* enqueue and dequeue */char data[MAXLEN], rcvbuf[MAXLEN];if(mq_send(myq,data,len,priority)<0) { /* errors */}nbytes = mq_receive(myq,rcvbuf,MAXLEN,&prio);
Operating Systems-85
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-86
Evaluating performance May want to test:
context switch time assumptions; scheduling policy.
Can use OS simulator to exercise process set, trace system behavior.
Operating Systems-87
Processes and caches Processes can cause additional caching
problems. Even if individual processes are well-behaved,
processes may interfere with each other. Worst-case execution time with bad
behavior is usually much worse than execution time with good cache behavior.
Operating Systems-88
Power optimization Power management: determining how
system resources are scheduled/used to control power consumption.
OS can manage for power just as it manages for time.
OS reduces power by shutting down units. May have partial shutdown modes.
Operating Systems-89
Power management and performance Power management and performance are
often at odds. Entering power-down mode consumes
energy, time.
Leaving power-down mode consumes energy, time.
Operating Systems-90
Simple power management policies Request-driven: power up once request is
received. Adds delay to response. Predictive shutdown: try to predict how
long you have before next request. May start up in advance of request in
anticipation of a new request. If you predict wrong, you will incur additional
delay while starting up.
Operating Systems-91
Probabilistic shutdown Assume service requests are probabilistic. Optimize expected values:
power consumption; response time.
Simple probabilistic: shut down after time Ton, turn back on after waiting for Toff.
Operating Systems-92
Advanced Configuration and Power Interface ACPI: open standard for power
management services.
Hardware platform
devicedrivers
ACPI BIOS
OS kernel
applications
powermanagement
Operating Systems-93
ACPI global power states G3: mechanical off G2: soft off
S1: low wake-up latency with no loss of context S2: low latency with loss of CPU/cache state S3: low latency with loss of all state except
memory S4: lowest-power state with all devices off
G1: sleeping state G0: working state
Operating Systems-94
Overview Processes Context switching Operating systems Scheduling policies Interprocess communication Evaluation and optimization Design example: telephone answering machin
e
Operating Systems-95
Theory of operation Compress audio using adaptive differential
pulse code modulation (ADPCM).
time
time
analog
ADPCM 3 2 1 -1 -2 -3
Operating Systems-96
ADPCM coding Coded in a small alphabet with positive
and negative values. {-3,-2,-1,1,2,3}
Minimize error between predicted value and actual signal value.
Operating Systems-97
ADPCM compression system
quantizer
integratorinverse
quantizer
encoder
inverse quantizer
integrator
decoder
samples
Operating Systems-98
Telephone system terms Subscriber line: line to phone. Central office: telephone switching system. Off-hook: phone active. On-hook: phone inactive.
Operating Systems-99
Real and simulated subscriber line Real subscriber line:
90V RMS ringing signal; companded analog signals; lightning protection, etc.
Simulated subscriber line: microphone input; speaker output; switches for ring, off-hook, etc.
Operating Systems-100
RequirementsInputs Telephone: voice samples, ring.
User interface: microphone, playmessages button, record OGM button.
Outputs Telephone: voice samples, on-hook/off-hook command.User interface: speaker, # messagesindicator, message light.
Functions Default mode: detects ring, signals off-hook, pays OGM, records ICMPlayback: play all messages, wait 5seconds for new playback.OGM editing: OGM up to 10 sec.
Performance About 30 minutes voice (@ 8kHz).
Manufacturing cost Consumer product range ($50)
Power AC plugPhysicalsize/weight
Comparable to desk phone.
Operating Systems-101
Comments on analysis DRAM requirement influenced by DRAM
price. Details of user interface protocol could be
tested on a PC-based prototype.
Operating Systems-102
Answering machine class diagram
Microphone*
Line-in*
Line-out*
Buttons*
Speaker*
Lights
Playback
Controls Record Outgoing-message
Incoming-message
1
1
1
1
1
1
1
11 1 1
11
1
1
1
1
*
*
*
*
Operating Systems-103
Physical interface classes
Line-out*
sample()pick-up()
Microphone*
sample()
Line-in*
sample()ring-indicator()
Speaker*
sample()
Buttons*
record-OGMplay
Lights*
messagesnum-messages
Operating Systems-104
Message classes
Message
lengthstart-adrsnext-msgsamples
Incoming-message
msg-time
Outgoing-message
length=30 sec
Operating Systems-105
Operational classes
Controls
operate()
Record
record-msg()
Playback
playback-msg()
Operating Systems-106
Software components Front panel module. Speaker module. Telephone line module. Telephone input and output modules. Compression module. Decompression module.
Operating Systems-107
Controls activate behavior
Compute buttons, line activations
Activations?
Play OGM Record OGM Play ICM Erase Answer
Wait for timeout
Erase
Play OGM
Allocate ICM
Record ICM
Operating Systems-108
Record-msg/playback-msg behaviors
nextadrs = 0
msg.samples[nextadrs] =sample(source)
End(source)F
T
record-msg
nextadrs = 0
speaker.samples() =msg.samples[nextadrs];
nextadrs++
nextadrs=msg.lengthF
T
playback-msg
Operating Systems-109
Hardware platform CPU. Memory. Front panel. 2 A/Ds:
subscriber line, microphone. 2 D/A:
subscriber line, speaker.
Operating Systems-110
Component design and testing Must test performance as well as testing.
Compression time shouldn’t dominate other tasks.
Test for error conditions: memory overflow; try to delete empty message set, etc.
Operating Systems-111
System integration and testing Can test partial integration on host
platform; full testing requires integration on target platform.
Simulate phone line for tests: it’s legal; easier to produce test conditions.