Mercurial > hg > Members > kono > nitros9-code

comparison docs/nitros9guide/chap5.chapter @ 145:099333bc912e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
More splitups.
author roug
date Sun, 07 Jul 2002 09:54:04 +0000
parents
children cc153d1671f7
comparison
equal deleted inserted replaced
144:f4e798ea65b9 145:099333bc912e
1 <chapter>
2 <title>Multiprogramming and Memory Management</title>
3 <para>
4 One of OS-9's most extraordinary abilities is multiprogramming,
5 which is sometimes called timesharing or multitasking. Simply
6 states, OS-9 lets you computer run more than one program at the same
7 time. This can be a tremendous advantage in many situations. For
8 example, you can be editing one program while another is being
9 printed. Or you can use your Color Computer to control household
10 automation and still be able to use it for routine work and
11 entertainment.
12 </para>
13 <para>
14 OS-9 uses this capability all the time for internal functions.
15 The simple way for you to do so is by putting a &quot;&amp;&quot; character at the
16 end of a command line which causes the shell to run your command as
17 a &quot;background task&quot;.
18 </para>
19 <para>
20 The information presented in this chapter is intended to give you
21 an insight into how OS-9 performs this amazing feat. You certainly
22 don't have to know every detail of how multiprogramming works in
23 order to use OS-9, but a basic working knowledge can help you
24 discover many new ways to use your Color Computer.
25 </para>
26 <para>
27 In order to allow several programs to run simultaneously and
28 without interference, OS-9 must perform many coordination and
29 resource allocation functions. The major system resources managed
30 by OS-9 are:
31 </para>
32 <simplelist>
33 <member>CPU Time</member>
34 <member>Memory</member>
35 <member>The input/output system</member>
36 </simplelist>
37 <para>
38 In order for the computer to have reasonable performance, these
39 resources must be managed in the most efficient manner possible.
40 Therefore, OS-9 uses many techniques and strategies to optimize
41 system throughput and capacity.
42 </para>
43
44 <section>
45 <title>Processor Time Allocation and Timeslicing</title>
46
47 <para>
48 CPU time is a resource that must be allocated wisely to maximize
49 the computer's throughput. It is characteristic of many programs to
50 spend much unproductive time waiting for various events, such as an
51 input/output operation. A good example is an interactive program
52 which communicates with a person at a terminal on a line-by line
53 basis. Every time the program has to wait for a line of characters
54 to be typed or displayed, it (typically) cannot do any useful
55 processing and would waste CPU time. An efficient multiprogramming
56 operating system such as OS-9 automatically assigns CPU time to only
57 those programs that can effectively use the, time.
58 </para>
59 <para>
60 OS-9 uses a technique called <emphasis>timeslicing</emphasis> which allows processes
61 to share CPU time with all other active processes. Timeslicing is
62 implemented using both hardware and software functions. The
63 system's CPU is interrupted by a real time clock many (60 in the
64 Color Computer) times each second. This basic time interval is
65 called a &quot;tick&quot;, hence, the interval between ticks is a time slice.
66 This technique is called timeslicing because each second of CPU time
67 is sliced up to be shared among several processes. This happens so
68 rapidly that to a human observer all processes appear to execute
69 continuously, unless the computer becomes overloaded with processing. If this
70 happens, a noticeable delay in response to terminal
71 input may occur, or &quot;batch&quot; programs may take much longer to run
72 than they ordinarily do. At any occurrence of a tick, OS-9 can suspend
73 execution of one program and begin execution of another. The
74 starting and stopping of programs is done in a manner that does not
75 affect the program's execution. How frequently a process is given
76 time slices depends upon its assigned priority relative to the
77 assigned priority of other active processes.
78 </para>
79 <para>
80 The percentage of CPU time assigned to any particular process
81 cannot be exactly computed because there are dynamic variables such
82 as time the process spends waiting for I/O devices. It can be
83 roughly approximated by dividing the process's priority by the sum
84 of the priority numbers of all processes:
85 </para>
86 <screen>
87
88 Process Priority
89 Process CPU Share = -------------------
90 Sum of All Active
91 Process' Priorities
92 </screen>
93 </section>
94
95 <section>
96 <title>Process States</title>
97
98 <para>
99 The CPU time allocation system automatically assigns programs one
100 of three &quot;states&quot; that describe their current status. Process
101 states are also important for coordinating process execution. A
102 process may be in one and only one state at any instant, although
103 state changes may be frequent. The states are:
104
105
106 </para>
107 <para>
108 <emphasis>ACTIVE:</emphasis>
109 processes which can currently perform useful processing.
110 These are the only processes assigned CPU time.
111 </para>
112 <para>
113 <emphasis>WAITING:</emphasis>
114 processes which have been suspended until another process
115 terminates. This state is used to coordinate execution of
116 sequential programs. The shell, for example, will be in the waiting
117 state during the time a command program it has initiated is running.
118
119 </para>
120 <para>
121 <emphasis>SLEEPING:</emphasis>
122 processes suspended by self-request for a specified time
123 interval or until receipt of a &quot;signal&quot;. Signals are internal
124 messages used to coordinate concurrent processes. This is the
125 typical state of programs which are waiting for input/output
126 operations.
127
128 </para>
129 <para>
130
131 Sleeping and waiting processes are not given CPU time until they
132 change to the active state.
133 </para>
134 </section>
135
136 <section>
137 <title>Creation of New Processes</title>
138
139 <para>
140 The sequence of operations required to create a new process and
141 initially allocate its resources (especially memory) are
142 automatically performed by OS-9's &quot;fork&quot; function. If for any
143 reason any part of the sequence cannot be performed the fork is
144 aborted and the prospective parent is passed an appropriate error
145 code. The most frequent reason for failure is unavailablity of
146 required resources (especially memory) or when the program specified
147 to be run cannot be found. A process can create many new processes,
148 subject only to the limitation of the amount of unassigned memory
149 available.
150 </para>
151 <para>
152 When a process creates a new process, the creator is called the
153 &quot;parent process&quot;, and the newly created process is called the &quot;child
154 process&quot;. The new child can itself become a parent by creating yet
155 another process. If a parent process creates more than one child
156 process, the children are called &quot;siblings&quot; with respect to each
157 other. If the parent/child relationship of all processes in the
158 system is examined, a hierarchical lineage becomes evident. In
159 fact, this hierarchy is a tree structure that resembles a family
160 tree. The &quot;family&quot; concept makes it easy to describe relationships
161 between processes, and so it is used extensively in descriptions of
162 OS-9's multiprogramming operations.
163 </para>
164 <para>
165 When the parent issues a fork request to OS-9, it must specify
166 the following required information:
167 </para>
168 <itemizedlist mark="square">
169 <listitem><para>
170 A PRIMARY MODULE, which is the name of the program to be
171 executed by the new process. The program can already be present
172 in memory, or OS-9 may load it from a mass storage file having
173 the same name (see 5.4.1).
174 </para></listitem>
175 <listitem><para>
176 PARAMETERS, which is data specified by the parent to be
177 passed to and used by the new process. This data is copied to
178 part of the child process' memory area. Parameters are
179 frequently used to pass file names, initialization values, etc.
180 The shell, passes command line parameters this way (see 4.1).
181 </para></listitem>
182 </itemizedlist>
183 <para>
184 The new process also &quot;inherits&quot; copies of certain of its parent's
185 properties. These are:
186 </para>
187 <itemizedlist mark="square">
188 <listitem><para>
189 A USER NUMBER which is used by the file security system and
190 is used to identify all processes belonging to a specific user
191 (this is not the same as the &quot;process ID&quot;, which identifies a
192 specific process) . This number is usually obtained from the
193 system password file when a user logs on. The system manager
194 always is user number zero (see 3.8).
195 </para></listitem>
196 <listitem><para>
197 STANDARD INPUT AND OUTPUT PATHS: the three paths (input,
198 output, and error/status) used for routine input and output.
199 Note that most paths (files) may be shared simultaneously by
200 two or more processes (see 4.2.2). The two current working
201 directories are also inherited.
202 </para></listitem>
203 <listitem><para>
204 PROCESS PRIORITY which determines what proportion of CPU
205 time the process receives with respect to others (see 5.1).
206 </para></listitem>
207 </itemizedlist>
208 <para>
209 As part of the fork operation, OS-9 automatically assigns:
210 </para>
211 <itemizedlist mark="square">
212 <listitem><para>
213 A PROCESS ID: a number from 1 to 255, which is used to
214 identify specific processes. Each process has a unique process
215 ID number (see 4.3.2).
216 </para></listitem>
217 <listitem><para>
218 MEMORY: enough memory required for the new process to run.
219 Level Two systems give each process a unique &quot;address space&quot;.
220 In Level One systems, all processes share the single address
221 space. A &quot;data area&quot;, used for the program's parameters,
222 variables, and stack is allocated for the process' exclusive
223 use. A second memory area may also be required to load the
224 program (primary module) if it is not resident in memory (see 5.4)..
225 </para></listitem>
226 </itemizedlist>
227 <para>
228 To summarize, the following items are given to or associated with
229 new processes:
230 </para>
231
232 <itemizedlist mark="square">
233 <listitem><para>
234 Primary Module (program module to be run)
235 </para></listitem>
236 <listitem><para>
237 Parameter(s) passed from parent to child
238 </para></listitem>
239 <listitem><para>
240 User Number
241 </para></listitem>
242 <listitem><para>
243 Standard I/O paths and working directories
244 </para></listitem>
245 <listitem><para>
246 Process Priority
247 </para></listitem>
248 <listitem><para>
249 Process ID
250 </para></listitem>
251 <listitem><para>
252 Memory
253 </para></listitem>
254 </itemizedlist>
255
256 </section>
257
258 <section>
259 <title>Basic Memory Management Functions</title>
260 <para>
261 An important OS-9 function is memory management. OS-9 automatically allocates
262 all system memory to itself and to processes, and
263 also keeps track of the logical <emphasis>contents</emphasis>
264 of memory (meaning which
265 program modules are resident in memory at any given time). The
266 result is that you seldom have to be bothered with the actual memory
267 addresses of programs or data.
268 </para>
269 <para>
270 Within the address space, memory is assigned from higher
271 addresses downward for program modules, and from lower addresses
272 upward for data areas, as shown below:
273 </para>
274 <screen>
275 +---------------------------+ highest address
276 ! program modules !
277 ! (RAM or ROM) !
278 ! !
279 ! - - - - - - - - - - - - - !
280 ! !
281 ! unused space !
282 ! (RAM or empty) !
283 ! !
284 ! - - - - - - - - - - - - - !
285 ! !
286 ! data areas !
287 ! (RAM) !
288 ! !
289 +---------------------------+ lowest address (0)
290 </screen>
291 <section>
292 <title>Loading Program Modules Into Memory</title>
293
294 <para>
295 When performing a fork operation, OS-9's first step is to attempt
296 to locate the requested program module by searching the &quot;module
297 directory&quot;, which has the address of every module present in memory.
298 The 6809 instruction set supports a type of program called
299 &quot;reentrant code&quot; which means the exact same &quot;copy&quot; of a program can
300 be shared by two or more different processes simultaneously without
301 affecting each other, provided that each &quot;incarnation&quot; of the
302 program has am independent memory area for its variables.
303 </para>
304 <para>
305 Almost all OS-9 family software is reentrant and can make most
306 efficient use of memory. For example, Basic09 requires 22K bytes of
307 memory to load into. If a request to run Basic09 is made, but
308 another user (process) had previously caused it to be loaded into
309 memory, both processes will share the same copy, instead of causing
310 another copy to be loaded (which would use an additional 22K of
311 memory). OS-9 automatically keeps track of how many processes are
312 using each program module and deletes the module (freeing its memory
313 for other uses) when all processes using the module have terminated.
314 </para>
315 <para>
316 If the requested program module is not already in memory, the
317 name is used as a pathlist (file name) and an attempt is made to
318 load the program from mass storage (see 3.9.4).
319 </para>
320 <para>
321 Every program module has a &quot;module header&quot; that describes the
322 program and its memory requirements. OS-9 uses this to determine
323 how much memory for variable storage should be allocated to the
324 process (it can be given more memory by specifying an optional
325 parameter on the shell command line). The module header also
326 includes other important descriptive information about the program,
327 and is an essential part of OS-9 operation at the machine language
328 level. A detailed description of memory modules and module headers
329 can be found in the &quot;OS-9 System Programmer's Manual&quot;.
330 </para>
331 <para>
332 Programs can also be explicitly loaded into memory using the
333 &quot;load&quot; command. As with fork, the program will actually be loaded
334 only if it is not already in memory. If the module is not in
335 memory, OS-9 will copy a candidate memory module from the file into
336 memory, verify the CRC, and then, if the module is not already in
337 the module directory, add the module to the directory. This process
338 is repeated until all the modules in the file are loaded, the 64K
339 memory limit is exceeded, or until a module with an invalid format
340 is encountered. OS-9 always links to the first module read from the
341 file.
342 </para>
343 <para>
344 If the program module <emphasis>is</emphasis> already in memory,
345 the load will proceed
346 as described above, loading the module from the specified file,
347 verifying the CRC, and when attempting to add the valid module to
348 the module directory, noticing that the module is already known, the
349 load merely increments the known module's link count (the number of
350 processes using the module.) The load command can be used to &quot;lock
351 a program into memory. This can be useful if the same program is to
352 be used frequently because the program will be kept in memory
353 continuously, instead of being loaded repeatedly.
354 </para>
355 <para>
356 The opposite of &quot;load&quot; is the &quot;unlink&quot; command, which decreases a
357 program module's link count by one. Recall that when this count becomes zero
358 (indicating the module in no longer used by any process),
359 the module is deleted, e.g., its memory is deallocated and its name
360 is removed from the module directory. The &quot;unlink&quot; command is
361 generally used in conjunction with the &quot;load&quot; command (programs
362 loaded by fork are automatically unlinked when the program
363 terminates).
364 </para>
365 <para>
366 Here is an example of the use of
367 &quot;load&quot; and &quot;unlink&quot; to lock a
368 program in memory. Suppose the &quot;copy&quot; command will be used five
369 times. Normally, the copy command would be loaded each time the
370 &quot;copy&quot; command is called. If the &quot;load&quot; command is used first,
371 &quot;copy&quot; will be locked into memory first, for example:
372 </para>
373 <screen>
374 OS9: load copy
375 OS9: copy file1 file1a
376 OS9: copy file2 file2a
377 OS9: copy file3 file3a
378 OS9: unlink copy
379 </screen>
380 <para>
381 It is important to use the &quot;unlink&quot; command after the program is no
382 longer needed, or the program will continue to occupy memory which
383 otherwise could be used for other purposes. Be very careful
384 <emphasis>not</emphasis> to
385 completely unlink modules in use by any process! This will cause the
386 memory used by the module to be deallocated and its contents
387 destroyed. This will certainly cause all programs using the
388 unlinked module to crash.
389 </para>
390 </section>
391
392 <section>
393 <title>Loading Multiple Programs</title>
394
395 <para>
396 Another important aspect of program loading is the ability to
397 have two or more programs resident in memory at the same time. This
398 is possible because all OS-9 program modules are &quot;position-independent
399 code&quot;, or &quot;PIC&quot;. PIC programs do not have to be loaded into
400 specific, predetermined memory addresses to work correctly, and can
401 therefore be loaded at different memory addresses at different
402 times. PIC programs require special types of machine language instructions
403 which few computers have. The ability of the 6809
404 microprocessor to use this type of program is one of its most
405 powerful features.
406 </para>
407 <para>
408 The &quot;load&quot; command can therefore be used two or more times (or a
409 single file may contain several memory modules, see 3.9.4), and each
410 program module will be automatically loaded at different,
411 non-overlapping addresses (most other operating systems write over the
412 previous program's memory whenever a new program is loaded). This
413 technique also relieves the user from having to be directly concerned with
414 absolute memory addresses. Any number of program modules
415 can be loaded until available system memory is full.
416 </para>
417 </section>
418
419 <section>
420 <title>Memory Fragmentation</title>
421
422 <para>
423 Even though PIC programs can be initially loaded at any address
424 where free memory is available, program modules cannot be relocated
425 dynamically afterwards, e.g., once a program is loaded it must
426 remain at the address at which it was originally loaded (however
427 Level Two systems can &quot;load&quot; (map) memory resident programs at
428 different addresses in each process' address space). This characteristic
429 can lead to a sometimes troublesome phenomenon called
430 &quot;memory fragmentation&quot;. When programs are loaded, they are assigned
431 the first sufficiently large block of memory at the highest address
432 possible in the address space. If a number of program modules are
433 loaded, and subsequently one or more modules which are located in
434 between other modules are &quot;unlinked&quot;, several fragments of free
435 memory space will exist. The sum of the sizes of the free memory
436 space may be quite large, but because they are scattered, not enough
437 space will exist in a single block to load a program module larger
438 than the largest free space.
439 </para>
440 <para>
441 The &quot;mfree&quot; command shows the location and size of each unused
442 memory area and the &quot;mdir e&quot; command shows the address, size, and
443 link (use) count of each module in the address space. These
444 commands can be used to detect fragmentation. Memory can usually be
445 de-fragmemted by unlinking scattered modules and reloading them.
446 <emphasis>Make certain</emphasis> none are in use before doing so.
447 </para>
448 </section>
449 </section>
450 </chapter>