1
00:00:00,650 --> 00:00:04,059
Here’s an old quiz
problem we can use to test

2
00:00:04,059 --> 00:00:06,260
our understanding of all
the factors that went

3
00:00:06,260 --> 00:00:10,900
into the final design of
our ReadKey() SVC code.

4
00:00:10,900 --> 00:00:13,400
We’re considering three
different versions (R1, R2,

5
00:00:13,400 --> 00:00:16,920
and R3) of the
ReadKey() SVC code,

6
00:00:16,920 --> 00:00:20,040
all variants of the various
attempts from the previous

7
00:00:20,040 --> 00:00:21,610
section.

8
00:00:21,610 --> 00:00:26,160
And there are three types of
systems (Models A, B, and C).

9
00:00:26,160 --> 00:00:28,420
We’ve been asked to
match the three handlers

10
00:00:28,420 --> 00:00:30,760
to the appropriate system.

11
00:00:30,760 --> 00:00:33,830
Looking at R1, we see it’s
similar to Attempt #2 from

12
00:00:33,830 --> 00:00:37,510
the previous section, except
it always reads from the same

13
00:00:37,510 --> 00:00:42,140
keyboard regardless of the
process making the SVC request.

14
00:00:42,140 --> 00:00:45,830
That wouldn’t make much sense
in a timesharing system since

15
00:00:45,830 --> 00:00:48,780
a single stream of input
characters would be shared

16
00:00:48,780 --> 00:00:50,870
across all the processes.

17
00:00:50,870 --> 00:00:55,140
So this handler must be intended
for the Model C system, which

18
00:00:55,140 --> 00:00:58,660
has only a single process.

19
00:00:58,660 --> 00:01:01,710
Looking at R2, we see it’s
similar to Attempt #1 from

20
00:01:01,710 --> 00:01:05,500
the previous section, which had
the fatal flaw of a potentially

21
00:01:05,500 --> 00:01:09,730
infinite loop if attempting
to read from an empty buffer.

22
00:01:09,730 --> 00:01:13,290
So this code would only run
successfully on the Model B

23
00:01:13,290 --> 00:01:17,170
system, which *does* allow
device interrupts even when

24
00:01:17,170 --> 00:01:20,760
the CPU is running
inside an SVC call.

25
00:01:20,760 --> 00:01:23,550
So the keyboard interrupt would
interrupt the while loop in R2

26
00:01:23,550 --> 00:01:26,000
and the next
iteration of the loop

27
00:01:26,000 --> 00:01:29,840
would discover that buffer
was no longer empty.

28
00:01:29,840 --> 00:01:32,240
By the process of
elimination that

29
00:01:32,240 --> 00:01:37,950
leaves the R3 handler to be
paired with the Model A system.

30
00:01:37,950 --> 00:01:40,620
R3 is Attempt #3 from
the previous section

31
00:01:40,620 --> 00:01:44,120
and is designed for our standard
system in which the kernel is

32
00:01:44,120 --> 00:01:46,720
uninterruptible.

33
00:01:46,720 --> 00:01:49,100
The problem goes on to say
that a fumble-fingered summer

34
00:01:49,100 --> 00:01:51,960
intern has jumbled up the
disks containing the handlers

35
00:01:51,960 --> 00:01:53,790
and sent an unknown
handler version

36
00:01:53,790 --> 00:01:57,990
to each user running one
of the three model systems.

37
00:01:57,990 --> 00:02:00,810
To atone for the mistake,
he’s been assigned the task

38
00:02:00,810 --> 00:02:04,360
of reading various user messages
sent after the user has tried

39
00:02:04,360 --> 00:02:08,289
the new handler disk on
their particular system.

40
00:02:08,289 --> 00:02:11,830
Based on the message, he’s been
asked to identify which handler

41
00:02:11,830 --> 00:02:15,430
disk and system
the user is using.

42
00:02:15,430 --> 00:02:18,420
The first message says “I
get compile-time errors;

43
00:02:18,420 --> 00:02:22,870
Scheduler and ProcTbl
are undefined!”

44
00:02:22,870 --> 00:02:25,780
On the right of the slide we’ve
included a table enumerating

45
00:02:25,780 --> 00:02:28,500
all the combinations of
handlers and systems,

46
00:02:28,500 --> 00:02:32,460
where we’ve X-ed the matches
from the previous slide

47
00:02:32,460 --> 00:02:35,800
since they correspond to
when the new handler would be

48
00:02:35,800 --> 00:02:38,740
the same as the old handler and
the user wouldn’t be sending

49
00:02:38,740 --> 00:02:40,970
a message!

50
00:02:40,970 --> 00:02:44,680
The phrase “Scheduler and
ProcTbl are undefined” wouldn’t

51
00:02:44,680 --> 00:02:49,130
apply to a timesharing system,
which includes both symbols.

52
00:02:49,130 --> 00:02:53,260
So we can eliminate the first
two columns from consideration.

53
00:02:53,260 --> 00:02:55,690
And we can also
eliminate the second row,

54
00:02:55,690 --> 00:03:00,540
since handler R2 doesn’t
include a call to Scheduler.

55
00:03:00,540 --> 00:03:03,000
So this message came
from a user trying

56
00:03:03,000 --> 00:03:07,210
to run handler R3
on a Model C system.

57
00:03:07,210 --> 00:03:09,480
Since Model C doesn’t
support timesharing,

58
00:03:09,480 --> 00:03:13,580
it would have neither Scheduler
nor ProcTbl as part the OS

59
00:03:13,580 --> 00:03:16,150
code.

60
00:03:16,150 --> 00:03:18,680
Okay, here’s the
next message: “Hey,

61
00:03:18,680 --> 00:03:22,430
now the system always reads
everybody’s input from keyboard

62
00:03:22,430 --> 00:03:23,680
0.

63
00:03:23,680 --> 00:03:27,070
Besides that, it seems to waste
a lot more CPU cycles than it

64
00:03:27,070 --> 00:03:28,980
used to.”

65
00:03:28,980 --> 00:03:32,430
R1 is the only handler that
always reads from keyboard 0,

66
00:03:32,430 --> 00:03:35,760
so we can eliminate
rows 2 and 3.

67
00:03:35,760 --> 00:03:39,520
So how can we tell if R1
is being run on a Model

68
00:03:39,520 --> 00:03:42,610
A or a Model B system?

69
00:03:42,610 --> 00:03:44,960
The R1 handler wastes
a lot of cycles

70
00:03:44,960 --> 00:03:47,790
looping while waiting
for a character to arrive

71
00:03:47,790 --> 00:03:51,580
and the implication is that
was a big change for the user

72
00:03:51,580 --> 00:03:54,560
since they’re complaining that
running R1 is wasting time

73
00:03:54,560 --> 00:03:57,550
compared to their
previous handler.

74
00:03:57,550 --> 00:04:01,100
If the user had been running
R2 on a model B system,

75
00:04:01,100 --> 00:04:04,300
they’re already used to the
performance hit of looping

76
00:04:04,300 --> 00:04:07,050
and so wouldn’t have noticed
a performance difference

77
00:04:07,050 --> 00:04:11,060
switching to R1, so we
can eliminate Model B from

78
00:04:11,060 --> 00:04:13,170
consideration.

79
00:04:13,170 --> 00:04:16,500
So this message came from
a user running handler R1

80
00:04:16,500 --> 00:04:20,260
on a model A system.

81
00:04:20,260 --> 00:04:23,590
The final message reads “Neat,
the new system seems to work

82
00:04:23,590 --> 00:04:24,590
fine.

83
00:04:24,590 --> 00:04:28,760
It even wastes less CPU
time than it used to!”

84
00:04:28,760 --> 00:04:32,030
Since the system works as
expected with the new handler,

85
00:04:32,030 --> 00:04:36,020
we can eliminate a
lot of possibilities.

86
00:04:36,020 --> 00:04:39,770
Handler R1 wouldn’t work fine
on a timesharing system since

87
00:04:39,770 --> 00:04:43,570
the user could tell that the
processes were now all reading

88
00:04:43,570 --> 00:04:46,530
from the same keyboard
buffer, so we can eliminate R1

89
00:04:46,530 --> 00:04:49,500
on Models A and B.

90
00:04:49,500 --> 00:04:54,180
And handlers R2 and R3 wouldn’t
work on a Model C system since

91
00:04:54,180 --> 00:04:57,250
that doesn’t include process
tables or scheduling,

92
00:04:57,250 --> 00:05:00,650
eliminating the
right-most column.

93
00:05:00,650 --> 00:05:04,940
Finally handler R2 wouldn’t work
on a Model A system with its

94
00:05:04,940 --> 00:05:08,910
uninterruptible kernel since any
attempt to read from an empty

95
00:05:08,910 --> 00:05:12,150
buffer would cause
an infinite loop.

96
00:05:12,150 --> 00:05:14,940
So, the message must have
been sent by a Model B

97
00:05:14,940 --> 00:05:16,430
user now running R3.

98
00:05:16,430 --> 00:05:19,560
Well, that was fun!

99
00:05:19,560 --> 00:05:22,260
Just like solving the logic
puzzles you find in games

100
00:05:22,260 --> 00:05:24,060
magazines :)