|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 1020-1021 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 1020
SEC. 12.2
INTERFACE DESIGN
989
Execution Paradigms
Architectural coherence is important at the user level, but equally important at
the system-call interface level. It is often useful to distinguish between the execu-
tion paradigm and the data paradigm, so we will do both, starting with the former.
Two execution paradigms are widespread: algorithmic and event driven. The
algorithmic paradigm
is based on the idea that a program is started to perform
some function that it knows in advance or gets from its parameters. That function
might be to compile a program, do the payroll, or fly an airplane to San Francisco.
The basic logic is hardwired into the code, with the program making system calls
from time to time to get user input, obtain operating system services, and so on.
This approach is outlined in Fig. 12-1(a).
main( )
main( )
{
{
int ... ;
mess
t msg;
init( );
init( );
do
something( );
while (get
message(&msg)) {
read(...);
switch (msg.type) {
do
something
else( );
case 1: ... ;
write(...);
case 2: ... ;
keep
going( );
case 3: ... ;
exit(0);
}
}
}
}
(a)
(b)
Figure 12-1.
(a) Algorithmic code. (b) Event-driven code.
The other execution paradigm is the
event-driven paradigm
of Fig. 12-1(b).
Here the program performs some kind of initialization, for example by displaying a
certain screen, and then waits for the operating system to tell it about the first
event. The event is often a key being struck or a mouse movement. This design is
useful for highly interactive programs.
Each of these ways of doing business engenders its own programming style.
In the algorithmic paradigm, algorithms are central and the operating system is
regarded as a service provider.
In the event-driven paradigm, the operating system
also provides services, but this role is overshadowed by its role as a coordinator of
user activities and a generator of events that are consumed by processes.
Data Paradigms
The execution paradigm is not the only one exported by the operating system.
An equally important one is the data paradigm.
The key question here is how sys-
tem structures and devices are presented to the programmer.
In early FORTRAN
Page 1021
990
OPERATING SYSTEM DESIGN
CHAP. 12
batch systems, everything was modeled as a sequential magnetic tape. Card decks
read in were treated as input tapes, card decks to be punched were treated as output
tapes, and output for the printer was treated as an output tape. Disk files were also
treated as tapes.
Random access to a file was possible only by rewinding the tape
corresponding to the file and reading it again.
The mapping was done using job control cards like these:
MOUNT(TAPE08, REEL781)
RUN(INPUT, MYDATA, OUTPUT, PUNCH, TAPE08)
The first card instructed the operator to go get tape reel 781 from the tape rack and
mount it on tape drive 8.
The second card instructed the operating system to run
the just-compiled FORTRAN program, mapping
INPUT
(meaning the card reader)
to logical tape 1, disk file
MYDATA
to logical tape 2, the printer (called
OUTPUT
)
to logical tape 3, the card punch (called
PUNCH
) to logical tape 4. and physical
tape drive 8 to logical tape 5.
FORTRAN had a well-defined syntax for reading and writing logical tapes.
By reading from logical tape 1, the program got card input.
By writing to logical
tape 3, output would later appear on the printer.
By reading from logical tape 5,
tape reel 781 could be read in, and so on.
Note that the tape idea was just a para-
digm to integrate the card reader, printer, punch, disk files, and tapes.
In this ex-
ample, only logical tape 5 was a physical tape; the rest were ordinary (spooled)
disk files. It was a primitive paradigm, but it was a start in the right direction.
Later came UNIX, which goes much further using the model of ‘‘everything is
afile.’’ Using this paradigm, all I/O devices are treated as files and can be opened
and manipulated as ordinary files. The C statements
fd1 = open("file1", O
RDWR);
fd2 = open("/dev/tty", O
RDWR)’
open a true disk file and the user’s terminal (keyboard + display).
Subsequent
statements can use
fd1
and
fd2
to read and write them, respectively. From that
point on, there is no difference between accessing the file and accessing the termi-
nal, except that seeks on the terminal are not allowed.
Not only does UNIX unify files and I/O devices, but it also allows other proc-
esses to be accessed over pipes as files. Furthermore, when mapped files are sup-
ported, a process can get at its own virtual memory as though it were a file. Finally,
in versions of UNIX that support the
/proc
file system, the C statement
fd3 = open("/proc/501", O
RDWR);
allows the process to (try to) access process 501’s memory for reading and writing
using file descriptor
fd3
, something useful for, say, a debugger.
Of course, just because someone says that everything is a file does not mean it
is true—for everything. For instance, UNIX network sockets may resemble files
somewhat, but they have their own, fairly different, socket API. Another operating
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
