![Metchnikoff read an epitome of his researches and of his answers to
attacks on his theory. Towards the end of the Congress the latter
had visibly acquired the suffrage of numerous scientists. Roux wrote
to me from London concerning my husband’s paper:
Metchnikoff is busy showing his preparations and, besides, he would not
tell you how great is his triumph. He spoke with such passion that he
carried everybody with him. I believe that, this evening, the phagocyte
theory is the richer by many friends.
Thus the researches made in recent years and the results of the
London Congress allowed us to consider the phagocyte theory of
immunity as being solidly established.
Yet, Behring’s discovery of antitoxins still hung over it like a sword of
Damocles; it was imperative that the respective parts played by
antitoxins and by phagocytes should be elucidated. With that object
in view, Metchnikoff undertook new researches and succeeded in
ascertaining once for all the narrow link between immunity and the
function of the phagocytes which probably elaborate the antitoxins
as a product of their digestion of vaccinal toxins. He drew this
conclusion from the fact that, in a rabbit vaccinated against hog-
cholera, the exudate devoid of phagocytes[20] is neither bactericidal,
nor antitoxic, nor attenuating, while it is so if it contains phagocytes.
Therefore a relation of causality exists between cells and the
acquired properties of humors. And the resistance of the animal is in
visible correlation with the degree of phagocytosis which is
manifested by it.
These results having been established, it seemed as if the last
rampart of the humoral theory had been taken by storm.
In the meanwhile the persistent and bitter opposition of physicians
to the phagocyte theory made a great impression on Metchnikoff,
and, while stimulating his energy in defence of his ideas, it
maintained him in a state of nervous excitement and even depressed
him.](https://image.slidesharecdn.com/2952418-250521133404-3cc4c619/85/Operating-System-Design-The-Xinu-Approach-2nd-Edition-Douglas-Comer-78-320.jpg)
Operating System Design The Xinu Approach 2nd Edition Douglas Comer
- 1. Operating System Design The Xinu Approach 2nd Edition Douglas Comer download https://ebookbell.com/product/operating-system-design-the-xinu- approach-2nd-edition-douglas-comer-5904836 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Operating System Design The Xinu Approach Linksys Version Douglas Comer https://ebookbell.com/product/operating-system-design-the-xinu- approach-linksys-version-douglas-comer-4081854 Operating System Design The Xinu Approach 2nd Edition Comer https://ebookbell.com/product/operating-system-design-the-xinu- approach-2nd-edition-comer-5066784 Introduction To Operating System Design And Implementation The Osp 2 Approach Michael Kifer https://ebookbell.com/product/introduction-to-operating-system-design- and-implementation-the-osp-2-approach-michael-kifer-978254 The Art Of Linux Kernel Design Illustrating The Operating System Design Principle And Implementation Dazhao https://ebookbell.com/product/the-art-of-linux-kernel-design- illustrating-the-operating-system-design-principle-and-implementation- dazhao-21354456
- 3. Controlbased Operating System Design Alberto Leva Martina Maggio https://ebookbell.com/product/controlbased-operating-system-design- alberto-leva-martina-maggio-4173116 The Design And Implementation Of The Freebsd Operating System Marshall Kirk Mckusick George V Nevilleneil Robert N M Watson https://ebookbell.com/product/the-design-and-implementation-of-the- freebsd-operating-system-marshall-kirk-mckusick-george-v-nevilleneil- robert-n-m-watson-57325212 The Design And Implementation Of The Freebsd Operating System Mckusick https://ebookbell.com/product/the-design-and-implementation-of-the- freebsd-operating-system-mckusick-22131492 Basic Principles Of An Operating System Learn The Internals And Design Principles Dr Priyanka Rathee https://ebookbell.com/product/basic-principles-of-an-operating-system- learn-the-internals-and-design-principles-dr-priyanka-rathee-12206632 The Design And Implementation Of The Freebsd Operating System Marshall Kirk Mckusick George V Nevilleneil Robert Nm Watson https://ebookbell.com/product/the-design-and-implementation-of-the- freebsd-operating-system-marshall-kirk-mckusick-george-v-nevilleneil- robert-nm-watson-55768234
- 5. Operating System Design Douglas Comer Comer The Xinu Approach Second Edition Operating System Design The Xinu Approach Second Edition Operating System Design Second Edition With Intel and ARM Examples • Access online or download to your smartphone, tablet or PC/Mac • Search the full text of this and other titles you own • Make and share notes and highlights • Copy and paste text and figures for use in your own documents • Customize your view by changing font size and layout WITH VITALSOURCE® EBOOK Widely lauded for avoiding the typical black box approach found in other operating system textbooks, the first edition of this bestselling book taught readers how an operating system works and explained how to build it from the ground up. Continuing to follow a logical pattern for system design, Operating System Design: The Xinu Approach, Sec- ond Edition removes the mystery from operating system design and consolidates the body of material into a sys- tematic discipline. It presents a hierarchical design paradigm that organizes major operating system components in an orderly, understandable manner. The book guides readers through the construction of a conventional process-based operating system using prac- tical, straightforward primitives. It gives the implementation details of one set of primitives, usually the most popu- lar set. Once readers understand how primitives can be implemented on conventional hardware, they can then easily implement alternative versions. The text begins with a bare machine and proceeds step-by-step through the design and implementation of the Xinu operating system. The Xinu code runs on many hardware platforms. This second edition has been completely rewritten to contrast operating systems for RISC and CISC processors. Encouraging hands-on experimentation, the book provides updated code throughout and examples for two low-cost experimenter boards: BeagleBone Black from ARM and Galileo from Intel. Features • Covers topics in the order a designer follows when building a system • Uses inexpensive embedded platforms from ARM and Intel • Describes the main components in the design hierarchy • Presents example software that illustrates the functions provided by each hierarchy level • Gives readers the foundation to implement alternative versions of primitives • Includes many practical examples and exercises that facilitate hands-on learning with the code • Offers updated code and other information on the author’s website Computer Science & Engineering K25117 w w w . c r c p r e s s . c o m K25117_cover.indd 1 1/6/15 10:33 AM
- 6. Operating System Design The Xinu Approach Second Edition
- 8. Operating System Design Douglas Comer The Xinu Approach Second Edition
- 9. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. Linux is a registered trade- mark of Linus Torvalds. In the United States, Linux is a trademark registered to Linus Torvalds. Microsoft Windows is a trademark of Microsoft Cor- poration. Microsoft is a registered trademark of Microsoft Corporation. Solaris is a trademark of Sun Microsystems, Incorporated. MIPS is a registered trademark of MIPS Technologies, Inc. IBM is a registered trademark of International Business Machines. Mac is a trademark of Apple, Inc. Intel is a registered trademark of Intel Corporation. Galileo is a registered trademark of Intel Corporation. mini-PCI Express is a trademark of Intel Corporation. ARM is a registered trademark of ARM Limited. Other trademarks are the property of their respective owners. CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2015 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Version Date: 20141204 International Standard Book Number-13: 978-1-4987-1244-6 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com
- 10. To my wife, Chris, and our children, Sharon and Scott
- 12. Contents xix Preface xxiii About the Author 3 Chapter 1 Introduction And Overview 1.1 Operating Systems 3 1.2 Approach Used In The Text 5 1.3 A Hierarchical Design 5 1.4 The Xinu Operating System 7 1.5 What An Operating System Is Not 8 1.6 An Operating System Viewed From The Outside 9 1.7 Remainder Of The Text 10 1.8 Perspective 11 1.9 Summary 11 15 Chapter 2 Concurrent Execution And Operating System Services 2.1 Introduction 15 2.2 Programming Models For Multiple Activities 16 2.3 Operating System Services 17 2.4 Concurrent Processing Concepts And Terminology 17 2.5 Distinction Between Sequential And Concurrent Programs 19 2.6 Multiple Processes Sharing A Single Piece Of Code 21 2.7 Process Exit And Process Termination 23 2.8 Shared Memory, Race Conditions, And Synchronization 24 2.9 Semaphores And Mutual Exclusion 28 2.10 Type Names Used In Xinu 30 2.11 Operating System Debugging With Kputc And Kprintf 31 2.12 Perspective 32 2.13 Summary 32
- 13. viii Contents 37 Chapter 3 An Overview Of The Hardware And Runtime Environment 3.1 Introduction 37 3.2 Physical And Logical Organizations Of A Platform 38 3.3 Instruction Sets 38 3.4 General-purpose Registers 39 3.5 I/O Buses And The Fetch-Store Paradigm 41 3.6 Direct Memory Access 42 3.7 The Bus Address Space 42 3.8 Bus Startup And Configuration 43 3.9 Calling Conventions And The Runtime Stack 44 3.10 Interrupts And Interrupt Processing 47 3.11 Vectored Interrupts 48 3.12 Exception Vectors And Exception Processing 48 3.13 Clock Hardware 49 3.14 Serial Communication 49 3.15 Polled vs. Interrupt-driven I/O 49 3.16 Storage Layout 50 3.17 Memory Protection 51 3.18 Hardware Details And A System On Chip Architecture 51 3.19 Perspective 52 3.20 Hardware References 52 57 Chapter 4 List And Queue Manipulation 4.1 Introduction 57 4.2 A Unified Structure For Linked Lists Of Processes 58 4.3 A Compact List Data Structure 59 4.4 Implementation Of The Queue Data Structure 61 4.5 Inline Queue Manipulation Functions 62 4.6 Basic Functions To Extract A Process From A List 63 4.7 FIFO Queue Manipulation 65 4.8 Manipulation Of Priority Queues 68 4.9 List Initialization 70 4.10 Perspective 71 4.11 Summary 72 75 Chapter 5 Scheduling And Context Switching 5.1 Introduction 75 5.2 The Process Table 76 5.3 Process States 79 5.4 Ready And Current States 80
- 14. Contents ix 5.5 A Scheduling Policy 80 5.6 Implementation Of Scheduling 81 5.7 Deferred Rescheduling 85 5.8 Implementation Of Context Switching 85 5.9 State Saved In Memory 86 5.10 Context Switch Operation 87 5.11 An Address At Which To Restart A Process 91 5.12 Concurrent Execution And A Null Process 92 5.13 Making A Process Ready And The Scheduling Invariant 93 5.14 Other Process Scheduling Algorithms 94 5.15 Perspective 95 5.16 Summary 95 99 Chapter 6 More Process Management 6.1 Introduction 99 6.2 Process Suspension And Resumption 99 6.3 Self–suspension And Information Hiding 100 6.4 The Concept Of A System Call 101 6.5 Interrupt Control With Disable And Restore 103 6.6 A System Call Template 104 6.7 System Call Return Values SYSERR And OK 105 6.8 Implementation Of Suspend 105 6.9 Suspending The Current Process 107 6.10 The Value Returned By Suspend 107 6.11 Process Termination And Process Exit 108 6.12 Process Creation 111 6.13 Other Process Manager Functions 115 6.14 Summary 117 123 Chapter 7 Coordination Of Concurrent Processes 7.1 Introduction 123 7.2 The Need For Synchronization 123 7.3 A Conceptual View Of Counting Semaphores 125 7.4 Avoidance Of Busy Waiting 125 7.5 Semaphore Policy And Process Selection 126 7.6 The Waiting State 127 7.7 Semaphore Data Structures 128 7.8 The Wait System Call 129 7.9 The Signal System Call 130 7.10 Static And Dynamic Semaphore Allocation 131 7.11 Example Implementation Of Dynamic Semaphores 132
- 15. x Contents 7.12 Semaphore Deletion 133 7.13 Semaphore Reset 135 7.14 Coordination Across Parallel Processors (Multicore) 136 7.15 Perspective 137 7.16 Summary 137 143 Chapter 8 Message Passing 8.1 Introduction 143 8.2 Two Types Of Message Passing Services 143 8.3 Limits On Resources Used By Messages 144 8.4 Message Passing Functions And State Transitions 145 8.5 Implementation Of Send 146 8.6 Implementation Of Receive 148 8.7 Implementation Of Non-Blocking Message Reception 149 8.8 Perspective 149 8.9 Summary 150 153 Chapter 9 Basic Memory Management 9.1 Introduction 153 9.2 Types Of Memory 153 9.3 Definition Of A Heavyweight Process 154 9.4 Memory Management In Our Example System 155 9.5 Program Segments And Regions Of Memory 156 9.6 Dynamic Memory Allocation 157 9.7 Design Of The Low–level Memory Manager 158 9.8 Allocation Strategy And Memory Persistence 159 9.9 Keeping Track Of Free Memory 159 9.10 Implementation Of Low–level Memory Management 160 9.11 Data Structure Definitions Used With Free Memory 161 9.12 Allocating Heap Storage 162 9.13 Allocating Stack Storage 165 9.14 Releasing Heap And Stack Storage 167 9.15 Perspective 170 9.16 Summary 170 175 Chapter 10 High-level Memory Management and Virtual Memory 10.1 Introduction 175 10.2 Partitioned Space Allocation 176 10.3 Buffer Pools 176 10.4 Allocating A Buffer 178
- 16. Contents xi 10.5 Returning Buffers To The Buffer Pool 179 10.6 Creating A Buffer Pool 181 10.7 Initializing The Buffer Pool Table 183 10.8 Virtual Memory And Memory Multiplexing 184 10.9 Real And Virtual Address Spaces 185 10.10 Hardware For Demand Paging 186 10.11 Address Translation With A Page Table 187 10.12 Metadata In A Page Table Entry 188 10.13 Demand Paging And Design Questions 189 10.14 Page Replacement And Global Clock 190 10.15 Perspective 191 10.16 Summary 191 195 Chapter 11 High-level Message Passing 11.1 Introduction 195 11.2 Inter–process Communication Ports 195 11.3 The Implementation Of Ports 196 11.4 Port Table Initialization 197 11.5 Port Creation 199 11.6 Sending A Message To A Port 200 11.7 Receiving A Message From A Port 202 11.8 Port Deletion And Reset 204 11.9 Perspective 207 11.10 Summary 207 211 Chapter 12 Interrupt Processing 12.1 Introduction 211 12.2 The Advantage Of Interrupts 212 12.3 Interrupt Processing 212 12.4 Vectored Interrupts 213 12.5 Integration Of Interrupts And Exceptions 214 12.6 ARM Exception Vectors Using Code 215 12.7 Assignment Of Device Interrupt Vector Numbers 219 12.8 Interrupt Dispatching 220 12.9 The Structure Of Interrupt Software 221 12.10 Disabling Interrupts 223 12.11 Constraints On Functions That Interrupt Code Invokes 225 12.12 The Need To Reschedule During An Interrupt 225 12.13 Rescheduling During An Interrupt 226 12.14 Perspective 227 12.15 Summary 228
- 17. xii Contents 233 Chapter 13 Real-time Clock Management 13.1 Introduction 233 13.2 Timed Events 234 13.3 Real-time Clocks And Timer Hardware 234 13.4 Handling Real-time Clock Interrupts 235 13.5 Delay And Preemption 236 13.6 Implementation Of Preemption 237 13.7 Efficient Management Of Delay With A Delta List 238 13.8 Delta List Implementation 239 13.9 Putting A Process To Sleep 241 13.10 Timed Message Reception 244 13.11 Awakening Sleeping Processes 248 13.12 Clock Interrupt Processing 249 13.13 Clock Initialization 251 13.14 Perspective 254 13.15 Summary 255 259 Chapter 14 Device–independent Input And Output 14.1 Introduction 259 14.2 Conceptual Organization Of I/O And Device Drivers 260 14.3 Interface And Driver Abstractions 261 14.4 An Example I/O Interface 262 14.5 The Open-Read-Write-Close Paradigm 263 14.6 Bindings For I/O Operations And Device Names 264 14.7 Device Names In Xinu 265 14.8 The Concept Of A Device Switch Table 265 14.9 Multiple Copies Of A Device And Shared Drivers 266 14.10 The Implementation Of High–level I/O Operations 269 14.11 Other High–level I/O Functions 271 14.12 Open, Close, And Reference Counting 275 14.13 Null And Error Entries In Devtab 277 14.14 Initialization Of The I/O System 278 14.15 Perspective 283 14.16 Summary 283 287 Chapter 15 An Example Device Driver 15.1 Introduction 287 15.2 Serial Communication Using UART Hardware 287 15.3 The Tty Abstraction 288 15.4 Organization Of A Tty Device Driver 289
- 18. Contents xiii 15.5 Request Queues And Buffers 290 15.6 Synchronization Of Upper Half And Lower Half 291 15.7 UART Hardware FIFOs And Driver Design 292 15.8 The Concept Of A Control Block 293 15.9 Tty Control Block And Data Declarations 293 15.10 Minor Device Numbers 296 15.11 Upper–half Tty Character Input (ttygetc) 297 15.12 Upper–half Tty Read Function (ttyread) 298 15.13 Upper–half Tty Character Output (ttyputc) 300 15.14 Starting Output (ttykickout) 301 15.15 Upper–half Tty Multiple Character Output (ttywrite) 302 15.16 Lower–half Tty Driver Function (ttyhandler) 303 15.17 Output Interrupt Processing (ttyhandle_out) 306 15.18 Tty Input Processing (ttyhandle_in) 308 15.19 Tty Control Block Initialization (ttyinit) 315 15.20 Device Driver Control (ttycontrol) 317 15.21 Perspective 319 15.22 Summary 320 325 Chapter 16 DMA Devices And Drivers (Ethernet) 16.1 Introduction 325 16.2 Direct Memory Access And Buffers 325 16.3 Multiple Buffers And Rings 326 16.4 An Example Ethernet Driver Using DMA 327 16.5 Device Hardware Definitions And Constants 328 16.6 Rings And Buffers In Memory 331 16.7 Definitions Of An Ethernet Control Block 333 16.8 Device And Driver Initialization 336 16.9 Reading From An Ethernet Device 343 16.10 Writing To An Ethernet Device 347 16.11 Handling Interrupts From An Ethernet Device 349 16.12 Ethernet Control Functions 352 16.13 Perspective 353 16.14 Summary 354 357 Chapter 17 A Minimal Internet Protocol Stack 17.1 Introduction 357 17.2 Required Functionality 358 17.3 Simultaneous Conversations, Timeouts, And Processes 359 17.4 A Consequence Of The Design 359 17.5 ARP Functions 360
- 19. xiv Contents 17.6 Definition Of A Network Packet 371 17.7 The Network Input Process 373 17.8 Definitions For IP 377 17.9 IP Functions 377 17.10 Definition Of The UDP Table 388 17.11 UDP Functions 389 17.12 Internet Control Message Protocol 403 17.13 Dynamic Host Configuration Protocol 404 17.14 Perspective 412 17.15 Summary 413 417 Chapter 18 A Remote Disk Driver 18.1 Introduction 417 18.2 The Disk Abstraction 417 18.3 Operations A Disk Driver Supports 418 18.4 Block Transfer And High–level I/O Functions 418 18.5 A Remote Disk Paradigm 419 18.6 The Important Concept Of Caching 420 18.7 Semantics Of Disk Operations 421 18.8 Definition Of Driver Data Structures 421 18.9 Driver Initialization (rdsinit) 427 18.10 The Upper–half Open Function (rdsopen) 430 18.11 The Remote Communication Function (rdscomm) 432 18.12 The Upper–half Write Function (rdswrite) 435 18.13 The Upper–half Read Function (rdsread) 438 18.14 Flushing Pending Requests 442 18.15 The Upper–half Control Function (rdscontrol) 442 18.16 Allocating A Disk Buffer (rdsbufalloc) 445 18.17 The Upper–half Close Function (rdsclose) 447 18.18 The Lower–half Communication Process (rdsprocess) 448 18.19 Perspective 453 18.20 Summary 454 459 Chapter 19 File Systems 19.1 What Is A File System? 459 19.2 An Example Set Of File Operations 460 19.3 Design Of A Local File System 461 19.4 Data Structures For The Xinu File System 461 19.5 Implementation Of The Index Manager 462 19.6 Clearing An Index Block (lfibclear) 467 19.7 Retrieving An Index Block (lfibget) 468
- 20. Contents xv 19.8 Storing An Index Block (lfibput) 469 19.9 Allocating An Index Block From The Free List (lfiballoc) 471 19.10 Allocating A Data Block From The Free List (lfdballoc) 472 19.11 Using The Device-Independent I/O Functions For Files 474 19.12 File System Device Configuration And Function Names 474 19.13 The Local File System Open Function (lfsopen) 475 19.14 Closing A File Pseudo-Device (lflclose) 483 19.15 Flushing Data To Disk (lfflush) 483 19.16 Bulk Transfer Functions For A File (lflwrite, lflread) 486 19.17 Seeking To A New Position In the File (lflseek) 488 19.18 Extracting One Byte From A File (lflgetc) 489 19.19 Changing One Byte In A File (lflputc) 490 19.20 Loading An Index Block And A Data Block (lfsetup) 492 19.21 Master File System Device Initialization (lfsinit) 496 19.22 Pseudo-Device Initialization (lflinit) 497 19.23 File Truncation (lftruncate) 499 19.24 Initial File System Creation (lfscreate) 501 19.25 Perspective 503 19.26 Summary 504 509 Chapter 20 A Remote File Mechanism 20.1 Introduction 509 20.2 Remote File Access 509 20.3 Remote File Semantics 510 20.4 Remote File Design And Messages 510 20.5 Remote File Server Communication (rfscomm) 518 20.6 Sending A Basic Message (rfsndmsg) 520 20.7 Network Byte Order 522 20.8 A Remote File System Using A Device Paradigm 522 20.9 Opening A Remote File (rfsopen) 524 20.10 Checking The File Mode (rfsgetmode) 527 20.11 Closing A Remote File (rflclose) 528 20.12 Reading From A Remote File (rflread) 529 20.13 Writing To A Remote File (rflwrite) 532 20.14 Seeking On A Remote File (rflseek) 535 20.15 Character I/O On A Remote File (rflgetc, rflputc) 536 20.16 Remote File System Control Functions (rfscontrol) 537 20.17 Initializing The Remote File System (rfsinit, rflinit) 541 20.18 Perspective 543 20.19 Summary 543
- 21. xvi Contents 547 Chapter 21 A Syntactic Namespace 21.1 Introduction 547 21.2 Transparency And A Namespace Abstraction 547 21.3 Myriad Naming Schemes 548 21.4 Naming System Design Alternatives 550 21.5 Thinking About Names Syntactically 550 21.6 Patterns And Replacements 551 21.7 Prefix Patterns 551 21.8 Implementation Of A Namespace 552 21.9 Namespace Data Structures And Constants 552 21.10 Adding Mappings To The Namespace Prefix Table 553 21.11 Mapping Names With The Prefix Table 555 21.12 Opening A Named File 559 21.13 Namespace Initialization 560 21.14 Ordering Entries In The Prefix Table 562 21.15 Choosing A Logical Namespace 563 21.16 A Default Hierarchy And The Null Prefix 564 21.17 Additional Object Manipulation Functions 564 21.18 Advantages And Limits Of The Namespace Approach 566 21.19 Generalized Patterns 566 21.20 Perspective 567 21.21 Summary 568 573 Chapter 22 System Initialization 22.1 Introduction 573 22.2 Bootstrap: Starting From Scratch 573 22.3 An Example Of Booting Over A Network 574 22.4 Operating System Initialization 575 22.5 Xinu Initialization 576 22.6 Xinu System Startup 579 22.7 Transforming A Program Into A Process 583 22.8 Perspective 584 22.9 Summary 584 589 Chapter 23 Subsystem Initialization And Memory Marking 23.1 Introduction 589 23.2 Self-initializing Modules 590 23.3 Self-initializing Modules In A Concurrent System 591 23.4 Self-initialization In The Presence Of Reboot 593 23.5 Initialization Using Accession Numbers 593
- 22. Contents xvii 23.6 A Generalized Memory Marking Scheme 595 23.7 Data Declarations For The Memory Marking System 596 23.8 Implementation Of Marking 598 23.9 Perspective 599 23.10 Summary 599 603 Chapter 24 Exception Handling 24.1 Introduction 603 24.2 Terminology: Faults, Checks, Traps, And Exceptions 603 24.3 Vectored Exceptions And Maskable Interrupts 604 24.4 Types Of Exceptions 604 24.5 Handling Exceptions 605 24.6 Exception Vector Initialization 606 24.7 Panic In The Face Of Catastrophic Problems 606 24.8 Implementation Of Panic 607 24.9 Perspective 607 24.10 Summary 608 611 Chapter 25 System Configuration 25.1 Introduction 611 25.2 The Need For Multiple Configurations 611 25.3 Configuration In Xinu 613 25.4 Contents Of The Xinu Configuration File 613 25.5 Computation Of Minor Device Numbers 616 25.6 Steps In Configuring A Xinu System 616 25.7 Perspective 617 25.8 Summary 617 621 Chapter 26 An Example User Interface: The Xinu Shell 26.1 Introduction 621 26.2 What Is A User Interface? 622 26.3 Commands And Design Principles 622 26.4 Design Decisions For A Simplified Shell 623 26.5 Shell Organization And Operation 623 26.6 The Definition Of Lexical Tokens 624 26.7 The Definition Of Command-Line Syntax 625 26.8 Implementation Of The Xinu Shell 625 26.9 Storage Of Tokens 628 26.10 Code For The Lexical Analyzer 629
- 23. xviii Contents 26.11 The Heart Of The Command Interpreter 633 26.12 Command Name Lookup And Builtin Processing 641 26.13 Arguments Passed To Commands 641 26.14 Passing Arguments To A Non-builtin Command 643 26.15 I/O Redirection 646 26.16 An Example Command Function (sleep) 647 26.17 Perspective 649 26.18 Summary 650 Appendix 1 Porting An Operating System 653 A1.1 Introduction 653 A1.2 Motivation: Evolving Hardware 654 A1.3 Steps Taken When Porting An Operating System 654 A1.4 Programming To Accommodate Change 660 A1.5 Summary 662 Appendix 2 Xinu Design Notes 663 A2.1 Introduction 663 A2.2 Overview 663 A2.3 Xinu Characteristics 664 A2.4 Xinu Implementation 665 A2.5 Major Concepts And Implementation 667 669 Index
- 24. Preface Building a computer operating system is like weaving a fine tapestry. In each case, the ultimate goal is a large, complex artifact with a unified and pleasing design, and in each case, the artifact is constructed with small, intricate steps. As in a tapestry, small details are essential because a minor mismatch is easily noticed — like stitches in a tapestry, each small piece added to an operating system must fit the overall design. Therefore, the mechanics of assembling pieces forms only a minor part of the overall process; a masterful creation must start with a pattern, and all artisans who work on the system must follow the pattern. Ironically, few operating system textbooks or courses explain underlying patterns and principles that form the basis for operating system construction. Students form the impression that an operating system is a black box, and textbooks reinforce the misimpression by explaining operating system features and focusing on how to use operating system facilities. More important, because they only learn how an operating system appears from the outside, students are left with the feeling that an operating sys- tem consists of a set of interface functions that are connected by a morass of mysterious code containing many machine-dependent tricks. Surprisingly, students often graduate with the impression that research on operating systems is over: existing operating systems, constructed by commercial companies and the open source community, suffice for all needs. Nothing could be further from the truth. Ironically, even though fewer companies are now producing conventional operat- ing systems for personal computers, the demand for operating system expertise is rising and companies are hiring students to work on operating systems. The demand arises from inexpensive microprocessors embedded in devices such as smart phones, video games, wireless sensors, cable and set-top boxes, and printers. When working in the embedded world, knowledge of principles and structures is essential because a programmer may be asked to build new mechanisms inside an operating system or to modify an operating system for new hardware. Furthermore, writing applications for embedded devices requires an appreciation for the underlying operating system — it is impossible to exploit the power of small embedded processors without understanding the subtleties of operating system design. This book removes the mystery from operating system design, and consolidates the body of material into a systematic discipline. It reviews the major system components, and imposes a hierarchical design paradigm that organizes the components in an order- ly, understandable manner. Unlike texts that survey the field by presenting as many al- ternatives as possible, the reader is guided through the construction of a conventional process-based operating system, using practical, straightforward primitives. The text begins with a bare machine, and proceeds step-by-step through the design and imple-
- 25. xx Operating System Design mentation of a small, elegant system. The system, called Xinu, serves as an example and a pattern for system design. Although it is small enough to fit into the text, Xinu includes all the components that constitute an ordinary operating system: memory management, process manage- ment, process coordination and synchronization, interprocess communication, real-time clock management, device-independent I/O, device drivers, network protocols, and a file system. The components are carefully organized into a multi-level hierarchy, making the interconnections among them clear and the design process easy to follow. Despite its size, Xinu retains much of the power of larger systems. Xinu is not a toy — it has been used in many commercial products by companies such as Mitsubishi, Lexmark, HP, IBM, and Woodward (woodward.com), Barnard Software, and Mantissa Corpora- tion. An important lesson to be learned is that good system design can be as important on small embedded systems as on large systems and that much of the power arises from choosing good abstractions. The book covers topics in the order a designer follows when building a system. Each chapter describes a component in the design hierarchy, and presents example software that illustrates the functions provided by that level of the hierarchy. The ap- proach has several advantages. First, each chapter explains a successively larger subset of the operating system than the previous chapters, making it possible to think about the design and implementation of a given level independent of the implementation of succeeding levels. Second, the details of a given chapter can be skipped on first reading — a reader only needs to understand the services that the level provides, not how those services are implemented. Third, reading the text sequentially allows a reader to under- stand a given function before the function is used to build others. Fourth, intellectually deep subjects like support for concurrency arise early, before higher-level services have been introduced. Readers will see that the most essential functionality only occupies a few lines of code, which allows us to defer the bulk of the code (networking and file systems) until later when the reader is better prepared to understand details and refer- ences to basic functions. Unlike many other books on operating systems, this text does not attempt to re- view every alternative for each system component, nor does it survey existing commer- cial systems. Instead, it shows the implementation details of one set of primitives, usu- ally the most popular set. For example, the chapter on process coordination explains semaphores (the most widely accepted process coordination primitives), relegating a discussion of other primitives (e.g., monitors) to the exercises. Our goal is to remove all the mystery about how primitives can be implemented on conventional hardware. Once the essential magic of a particular set of primitives is understood, the implementa- tion of alternative versions will be easy to master. The Xinu code presented in the text runs on many hardware platforms. We will focus on two low-cost experimenter boards that use two popular processor architectures: a Galileo board that contains an Intel (x86) processor and a BeagleBone Black that con- tains an ARM processor. The paradigm is that a programmer uses conventional tools (editor, compiler, and linker) to create a Xinu image. The image is then loaded onto a target board, and the board boots the Xinu operating system.
- 26. Preface xxi The book is designed for advanced undergraduate or graduate-level courses, and for computing professionals who want to understand operating systems. Although there is nothing inherently difficult about any topic, covering most of the material in one semester demands an extremely rapid pace usually unattainable by undergraduates. Few undergraduates are adept at reading code, and fewer still understand the details of a run- time environment or machine architecture. Thus, they need to be guided through the chapters on process management and process synchronization carefully. Choosing items to omit depends largely on the background of students who take the course. If time is limited, I recommend covering Chapters 1–7 (process management), 9 (basic memory management), 12 (interrupt processing), 13 (clock management), 14 (device- independent I/O), and 19 (file systems). If students have taken a data structures course that covers memory management and list manipulation, Chapters 4 and 9 can be skipped. It is important for students to understand that most operating systems include network communication. If they will take a separate course in networking, however, they can skip Chapter 17 on network protocols. The text includes chapters on both a re- mote disk system (18) and a remote file system (20); one of the two can be skipped. The chapter on a remote disk system may be slightly more pertinent because it intro- duces the topic of disk block caching, which is central in many operating systems. In grad courses, class time can be spent discussing motivations, principles, trade- offs, alternative sets of primitives, and alternative implementations. Students should emerge with a firm understanding of the process model and the relationship between in- terrupts and processes as well as the ability to understand, create, and modify system components. They should have a complete mental model of the entire system, and know how all the pieces interact. Two topics should be included in both graduate and undergraduate courses: the important metamorphosis that occurs during startup when a sequential program is transformed into a process, and the transformation in the shell when a sequence of characters on an input line become string arguments passed to a command process. In all cases, learning improves dramatically if students have hands-on experience with the system. The low cost of the boards we have selected (they are available for less than $50 US) means each student can afford to purchase a board and the cables needed to connect it to a laptop or other development computer. Ideally, they can start to use the system in the first few days or weeks of the class before they try to under- stand the internal structure. Chapter 1 provides a few examples and encourages experi- mentation. (It is surprising how many students take operating system courses without ever writing a concurrent program or using system facilities.) Many of the exercises suggest improvements, experiments, and alternative implementations. Larger projects are also possible. Examples that have been used with various hardware include: a pag- ing system, mechanisms to synchronize execution across computers, and the design of a virtual network. Other students have transported Xinu to various processors or built de- vice drivers for various I/O devices. Of course, a background in programming is as- sumed — working on the code requires a knowledge of the C programming language and a basic understanding of data structures, including linked lists, stacks, and queues.
- 27. xxii Operating System Design At Purdue, we have a lab with an automated system providing access to the experi- menter boards. A student uses cross-development tools on a conventional Linux system to create a Xinu image. The student then runs an application that uses the lab network to allocate one of the boards, load the image onto the board, connect the console line from the board to a window on the student’s screen, and boot the image. Because the hardware is inexpensive, a lab can be constructed at very low cost. For details, contact the author or look on the website: www.xinu.cs.purdue.edu I owe much to my experiences, good and bad, with commercially available operat- ing systems. Although Xinu differs internally from existing systems, the fundamental ideas are not new. Many basic ideas and names have been taken from Unix. However, readers should be aware that many of the function arguments and the internal structure of the two systems differ dramatically — applications written for one system will not run on the other without modification. Xinu is not Unix. I gratefully acknowledge the help of many people who contributed ideas, hard work, and enthusiasm to the Xinu project. Over the years, many graduate students at Purdue have worked on the system, ported it, and written device drivers. The version in this book represents a complete rewrite, and many students at Purdue contributed. As we updated the code, we strove to preserve the elegance of the original design. Rajas Karandikar and Jim Lembke created drivers and the multi-step downloading system used on the Galileo. Students in my operating systems class, including Andres Bravo, Gregory Essertel, Michael Phay, Sang Rhee, and Checed Rodgers, found problems and contributed to the code. Special thanks go to my wife and partner, Christine, whose careful editing and suggestions made many improvements throughout. Douglas Comer
- 28. About the Author Douglas Comer, Distinguished Professor of Computer Science at Purdue Universi- ty, is an internationally recognized expert on computer networking, the TCP/IP proto- cols, the Internet, and operating systems design. The author of numerous refereed arti- cles and technical books, he is a pioneer in the development of curriculum and labora- tories for research and education. A prolific author, Dr. Comer’s popular books have been translated into sixteen languages, and are used in industry as well as computer science, engineering, and busi- ness departments around the world. His landmark three-volume series Internetworking With TCP/IP revolutionized networking and network education. His textbooks and in- novative laboratory manuals have shaped and continue to shape graduate and undergra- duate curricula. The accuracy and insight of Dr. Comer’s books reflect his extensive background in computer systems. His research spans both hardware and software. He has created the Xinu operating system, written device drivers, and implemented network protocol software for conventional computers as well as network processors. Software that has resulted from Dr. Comer’s research has been used by industry in a variety of products. Dr. Comer has created and teaches courses on network protocols, operating sys- tems, and computer architecture for a variety of audiences, including courses for en- gineers as well as academic audiences. His innovative educational laboratories allow him and his students to design and implement working prototypes of large, complex systems, and measure the performance of the resulting prototypes. He continues to teach at companies, universities, and conferences around the world. In addition, Dr. Comer consults for industry on the design of computer networks and systems. For twenty years, Professor Comer served as editor-in-chief of the research journal Software — Practice and Experience. While on an extended leave from Purdue, he served as Vice President of Research at Cisco Systems. He is a Fellow of the ACM, a Fellow of the Purdue Teaching Academy, and a recipient of numerous awards, includ- ing a Usenix Lifetime Achievement award. Additional information about Dr. Comer can be found at: www.cs.purdue.edu/ people/ comer and information about his books can be found at: www.comerbooks.com
- 30. Chapter Contents 1.1 Operating Systems, 3 1.2 Approach Used In The Text, 5 1.3 A Hierarchical Design, 5 1.4 The Xinu Operating System, 7 1.5 What An Operating System Is Not, 8 1.6 An Operating System Viewed From The Outside, 9 1.7 Remainder Of The Text, 10 1.8 Perspective, 11 1.9 Summary, 11
- 32. 1 Introduction And Overview Our little systems have their day. — Alfred, Lord Tennyson 1.1 Operating Systems Hidden in every intelligent device and computer system is the software that con- trols processing, manages resources, and communicates with peripherals such as display screens, disks, computer networks, and printers. Collectively, the code that performs control and coordination chores has been referred to as an executive, a monitor, a task manager, and a kernel; we will use the broader term operating system. Computer operating systems are among the most complex objects created by mankind: they allow multiple computational processes and users to share a processor simultaneously, protect data from unauthorized access, and keep independent input/output (I/O) devices operating correctly. The high-level services an operating system offers are all achieved by executing intricately detailed, low-level hardware in- structions. Interestingly, an operating system is not an independent mechanism that controls a computer from the outside — it consists of software that is executed by the same processor that executes applications. In fact, when a processor is executing an ap- plication, the processor cannot be executing the operating system and vice versa. Arranging mechanisms that guarantee an operating system will always regain con- trol after an application runs complicates system design. The most impressive aspect of an operating system, however, arises from the difference in functionality between the services offered and underlying hardware: an operating system provides impressively high-level services over extremely low-level hardware. As the book proceeds, we will understand how crude the underlying hardware can be, and see how much system software is required to handle even a simple device such as the serial I/O device used 3
- 33. 4 Introduction And Overview Chap. 1 for a keyboard or mouse. The philosophy is straightforward: an operating system should provide abstractions that make programming easier rather than abstractions that reflect the underlying hardware. Thus, we conclude: An operating system is designed to hide low-level hardware details and to create an abstract machine that provides applications with high-level services. Operating system design is not a well-known craft. In the beginning, because computers were scarce and expensive, only a few programmers had an opportunity to work on operating systems. By the time advances in micro-electronic technology re- duced fabrication costs and made personal computers available, operating systems had become commodities, and few programmers need to work on them. Interestingly, mi- croprocessors have become so inexpensive that most electronic devices are now con- structed from programmable processors rather than from discrete logic. As a result, designing and implementing software systems for microprocessors and microcontrollers is no longer a task reserved for a few specialists; it has become a skill expected of com- petent systems programmers. Fortunately, our understanding of operating systems has grown along with the technology we use to produce new machines. Researchers have explored fundamental issues, formulated design principles, identified essential components, and devised ways that components can work together. More important, researchers have identified abstractions, such as files and current processes, that are common to all operating sys- tems, and have found efficient implementations for the abstractions. Finally, we have learned how to organize the components of an operating system into a meaningful struc- ture that simplifies system design and implementation. Compared to its early counterparts, a modern system is simple, clean, and portable. A well-designed system follows a basic pattern that partitions software into a set of basic components. As a result, a modern system can be easier to understand and modi- fy, can contain less code, and has less processing overhead than early systems. Vendors that sell large commercial operating systems include many extra software components along with an operating system. For example, a typical software distribu- tion includes compilers, linkers, loaders, library functions, and a set of applications. To distinguish between the extras and the basic system, we sometimes use the term kernel to refer to the code that remains resident in memory and provides key services such as support for concurrent processes. Throughout the text, we will assume the term operat- ing system refers to the kernel, and does not include all additional facilities. A design that minimizes the facilities in a kernel is sometimes called a microkernel design; our discussions will concentrate on a microkernel.
- 34. Sec. 1.2 Approach Used In The Text 5 1.2 Approach Used In The Text This book is a guide to the structure, design, and implementation of operating sys- tem kernels. Instead of merely surveying extant systems, listing their features, and describing functionality abstractly, the book takes an engineering approach. It explains how to construct each OS abstraction, and shows how the individual abstractions can be organized into an elegant, efficient design. Our approach provides two advantages. First, because the text covers every part of the system, a reader will see how an entire system fits together, not merely how one or two parts interact. Second, because source code is available for all pieces described in the text, no mystery remains about any part of the implementation — a reader can ob- tain a copy of the system to examine, modify, instrument, measure, extend, or transport to another architecture. By the end of the book, a reader will see how each piece of an operating system fits into the design, and will be prepared to understand alternative design choices. Our focus on implementation means that the software forms an integral part of the text. In fact, the code provides a centerpiece for discussion; one must read and study the program listings to appreciate the underlying subtlety and engineering detail. The example code is minimal, which means a reader can concentrate on concepts without wading through many pages of code. Some of the exercises suggest improvements or modifications that require a reader to delve into details or invent alternatives; a skillful programmer will find additional ways to improve and extend the system. 1.3 A Hierarchical Design If designed well, the interior of an operating system can be as elegant and clean as the best application program. The design described in this book achieves elegance by partitioning system functions into eight major categories, and organizing the com- ponents into a multi-level hierarchy. Each level of the system provides an abstract ser- vice, implemented in terms of the abstract services provided by lower levels. The ap- proach offers a property that will become apparent: successively larger subsets of the levels can be selected to form successively more powerful systems. We will see how a hierarchical approach provides a model for designers that helps reduce complexity. Another important property of our approach arises from runtime efficiency — a designer can structure pieces of an operating system into a hierarchy without introduc- ing extra overhead. In particular, our approach differs from a conventional layered sys- tem in which a function at level K can only invoke functions at level K – 1. In our multi-level approach, the hierarchy only provides a conceptual model for a designer — at runtime, a function at a given level of the hierarchy can invoke any of the functions in lower levels directly. We will see that direct invocation makes the entire system effi- cient.
- 35. 6 Introduction And Overview Chap. 1 Figure 1.1 illustrates the hierarchy used in the text, gives a preview of the com- ponents we will discuss, and shows the structure into which all pieces are organized. HARDWARE MEMORY MANAGER PROCESS MANAGER PROCESS COORDINATION INTERPROCESS COMMUNICATION REAL-TIME CLOCK MANAGER DEVICE MANAGER AND DEVICE DRIVERS INTERMACHINE COMMUNICATION FILE SYSTEM APPLICATION PROGRAMS Figure 1.1 The multi-level organization used in the text.
- 36. Sec. 1.3 A Hierarchical Design 7 At the heart of the hierarchy lies the computer hardware. Although not part of the operating system itself, modern hardware includes features that allow tight integration with an operating system. Thus, we think of the hardware as forming level zero of our hierarchy. Building out from the hardware, each higher level of operating system software provides more powerful primitives that shield applications from the raw hardware. A memory manager controls and allocates memory. Process management forms the most fundamental component of the operating system, and includes a scheduler and context switch. Functions in the next level constitute the rest of the process manager, providing primitives to create, kill, suspend, and resume processes. Just beyond the process manager comes a process coordination component that implements semaphores. Func- tions for real-time clock management occupy the next level, and allow application software to delay for a specified time. On top of the real-time clock level lies a level of device-independent I/O routines that provide familiar services, such as read and write. Above the device routines, a level implements network communication, and the level above that implements a file system. Application programs occupy the highest concep- tual level of the hierarchy — an application has access to all the facilities provided by lower levels. The internal organization of a system should not be confused with the services the system provides. Although components are organized into levels to make the design and implementation cleaner, the resulting hierarchical structure does not restrict system calls at runtime. That is, once the system has been built, facilities from all levels of the hierarchy can be exposed to applications. For example, an application can invoke sema- phore functions, such as wait and signal, that reside in the process coordination level just as easily as it can invoke functions such as putc that reside in an outer level. Thus, the multi-level structure describes only the internal implementation, and does not res- trict the services the system provides. 1.4 The Xinu Operating System Examples in the book are taken from the Xinu† operating system. Xinu is a small, elegant system that is intended for use in an embedded environment, such as a cell phone or an MP3 player. Typically, Xinu is loaded into memory along with a fixed set of applications when the system boots. Of course, if memory is constrained or the hardware architecture uses a separate memory for instructions, Xinu can be executed from Flash or other read-only memory. In a typical system, however, executing from main memory produces higher performance. Xinu is not a toy; it is a powerful operating system that has been used in commer- cial products. For example, Xinu was used in pinball games sold under the Williams/ Bally brand (the major manufacturer), Woodward Corporation uses Xinu to control large gas/steam and diesel/steam turbine engines, and Lexmark Corporation used Xinu as the operating system in its printers until 2005. In each case, when the device was powered on, the hardware loaded a memory image that contained Xinu. †The name stands for Xinu Is Not Unix. As we will see, the internal structure of Xinu differs completely from the internal structure of Unix (or Linux). Xinu is smaller, more elegant, and easier to understand.
- 37. 8 Introduction And Overview Chap. 1 Xinu contains the fundamental components of an operating system, including: process, memory, and timer management mechanisms, interprocess communication fa- cilities, device-independent I/O functions, and Internet protocol software. Xinu can control I/O devices and perform chores such as reading keystrokes from a keyboard or keypad, displaying characters on an output device, managing multiple, simultaneous computations, controlling timers, passing messages between computations, and allowing applications to access the Internet. Xinu illustrates how the hierarchical design that is described above applies in prac- tice. It also shows how all the pieces of an operating system function as a uniform, in- tegrated whole, and how an operating system makes services available to application programs. 1.5 What An Operating System Is Not Before proceeding into the design of an operating system, we should agree on what we are about to study. Surprisingly, many programmers do not have a correct intuitive definition of an operating system. Perhaps the problem arises because vendors and computer professionals often apply the terminology broadly to refer to all software sup- plied by a vendor as well as the operating system itself, or perhaps confusion arises be- cause few programmers access system services directly. In any case, we can clarify the definition quickly by ruling out well-known items that are not part of the operating sys- tem kernel. First, an operating system is not a language or a compiler. Of course, an operating system must be written in some language, and languages have been designed that incor- porate operating systems features and facilities. Further confusion arises because a software vendor may offer one or more compilers that have been integrated with their operating system. However, an operating system does not depend on an integrated language facility — we will see that a system can be constructed using a conventional language and a conventional compiler. Second, an operating system is not a windowing system or a browser. Many com- puters and electronic devices have a screen that is capable of displaying graphics, and sophisticated systems permit applications to create and control multiple, independent windows. Although windowing mechanisms rely on an operating system, a windowing system can be replaced without replacing the operating system. Third, an operating system is not a command interpreter. Embedded systems often include a Command Line Interface (CLI); some embedded systems rely on a CLI for all control. In a modern operating system, however, the command interpreter operates as an application program, and the interpreter can be changed without modifying the underlying system. Fourth, an operating system is not a library of functions or methods. Almost all application programs use library functions, and the software found in libraries can offer significant convenience and functionality. Some operating systems even employ an op- timization that allows code from a library to be loaded in memory and shared among all
- 38. Sec. 1.5 What An Operating System Is Not 9 applications. Despite the close relationship, library software remains independent of the underlying operating system. Fifth, an operating system is not the first code that runs after a computer is powered on. Instead, the computer contains firmware (i.e., a program in non-volatile memory) that initializes various pieces of hardware, loads a copy of the operating sys- tem into memory, and then jumps to the beginning of the operating system. On a PC, for example, the firmware is known as the Basic Input Output System (BIOS). We will learn more about bootstrapping in Chapter 22. 1.6 An Operating System Viewed From The Outside The essence of an operating system lies in the services it provides to applications. An application accesses operating system services by making system calls. In source code, a system call appears to be a conventional function invocation. At runtime, how- ever, a system call and a conventional function call differ. Instead of transferring con- trol to another function, a system call transfers control to the operating system, which performs the requested service for the application. Taken as a set, system calls establish a well-defined boundary between applications and the underlying operating system that is known as an Application Program Interface (API)†. The API defines the services that the system provides as well as the details of how an application uses the services. To appreciate the interior of an operating system, one must first understand the characteristics of the API and see how applications use the services. This chapter intro- duces a few fundamental services, using examples from the Xinu operating system to il- lustrate the concepts. For example, the Xinu function putc writes a single character to a specified I/O device. Putc takes two arguments: a device identifier and a character to write. File ex1.c contains an example C program that writes the message “hi” on the console when run under Xinu: / /* * e ex x1 1. .c c - - m ma ai in n * */ / # #i in nc cl lu ud de e < <x xi in nu u. .h h> > / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * m ma ai in n - - W Wr ri it te e " "h hi i" " o on n t th he e c co on ns so ol le e * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d m ma ai in n( (v vo oi id d) ) { { p pu ut tc c( (C CO ON NS SO OL LE E, , ’ ’h h’ ’) ); ; p pu ut tc c( (C CO ON NS SO OL LE E, , ’ ’i i’ ’) ); ; p pu ut tc c( (C CO ON NS SO OL LE E, , ’ ’ n n’ ’) ); ; } } †The interface is also known as a system call interface or the kernel interface.
- 39. 10 Introduction And Overview Chap. 1 The code introduces several conventions used throughout Xinu. The statement: # #i in nc cl lu ud de e < <x xi in nu u. .h h> > inserts a set of declarations into a source program that allows the program to reference operating system parameters. For example, the Xinu configuration file defines symbolic constant CONSOLE to correspond to a console serial device a programmer uses to in- teract with the embedded system. Later, we will see that xinu.h contains a series of #include statements that reference files needed by the Xinu system, and we will learn how names like CONSOLE become synonymous with devices; for now, it is sufficient to know that the include statement must appear in any Xinu application. To permit communication with an embedded system (e.g., for debugging), the seri- al device on the embedded system can be connected to a terminal application on a con- ventional computer. Each time a user presses a key on the computer’s keyboard, the terminal application sends the keystroke over the serial line to the embedded system. Similarly, each time the embedded system sends a character to the serial device, the ter- minal application displays the character on the user’s screen. Thus, a console provides two-way communication between the embedded system and the outside world. The main program listed above writes three characters to the console serial device: “h”, “i”, and a line feed (known as NEWLINE). The line feed is a control character that moves the cursor to the beginning of the next line. Xinu does not perform any special operations when the program sends control characters — control characters are merely passed on to the serial device just like alphanumeric characters. A control character has been included in the example to illustrate that putc is not line-oriented; in Xinu, a pro- grammer is responsible for terminating a line. The example source file introduces two important conventions followed throughout the book. First, the file begins with a one-line comment that contains the name of the file (ex1.c). If a source file contains multiple functions, the name of each appears on the comment line. Knowing the names of files will help you locate them in a machine- readable copy of Xinu. Second, the file contains a block comment that identifies the start of each function (main). Having a block comment before each function makes it easy to locate functions in a given file. 1.7 Remainder Of The Text The remainder of the text proceeds through the design of a system that follows the multi-level organization that Figure 1.1 illustrates. Chapter 2 describes concurrent pro- gramming and the services an operating system supplies. Successive chapters consider the levels in roughly the same order as they are designed and built: from the innermost outward. Each chapter explains the role of one level in the system, describes new abstractions, and illustrates the details with source code. Taken together, the chapters describe a complete, working system and explain how the components fit together in a clean and elegant design.
- 40. Sec. 1.7 Remainder Of The Text 11 Although the bottom-up approach may seem awkward at first, it shows how an operating system designer builds a system. The overall structure of the system will start to become clear by Chapter 9. By the end of Chapter 14, readers will understand a minimal kernel capable of supporting concurrent programs. By Chapter 20, the system will include remote file access, and by Chapter 22, the design will include a complete set of operating system functions and code to initialize the entire system. 1.8 Perspective Why study operating systems? It may seem pointless because commercial systems are widely available and relatively few programmers write operating system code. However, a strong motivation exists: even in small embedded systems, applications run on top of an operating system and use the services it provides. Therefore, understand- ing how an operating system works internally helps a programmer appreciate concurrent processing and make sensible choices about system services. In some cases, the behavior of application software can only be understood, and problems can only be solved, by understanding how an operating system manages concurrent process execu- tion. The key to learning operating systems lies in persistence. A concurrent paradigm requires you to think about computer programs in new ways. Until you grasp the basics, it may seem confusing. Fortunately, you will not be overwhelmed with code — some of the most important ideas are contained neatly in a few lines of code. Once you understand what’s going on, you will be able to read operating systems code easily, understand why process coordination is needed, and see how functions work together. By the end of the text, you will be able to write or modify operating systems functions. 1.9 Summary An operating system provides a set of convenient, high-level services over low- level hardware. Because most applications use operating system services, programmers need to understand operating system principles. Programmers who work on embedded devices need to understand operating system design more deeply. Using a hierarchical structure can make an operating system easier to design, understand, and modify. The text takes a practical approach. Instead of merely describing commercial sys- tems or listing operating system features, it uses an example system, Xinu, to illustrate how a system can be designed. Although it is small and elegant, Xinu is not a toy — it has been used in commercial products. Xinu follows a multi-level design in which software components are organized into eight conceptual levels. The text explains one level of the system at a time, beginning with the raw hardware and ending with a work- ing operating system.
- 41. 12 Introduction And Overview Chap. 1 EXERCISES 1.1 Should an operating system make hardware facilities available to application programs? Why or why not? 1.2 What are the advantages of using a real operating system in examples? 1.3 What are the eight major components of an operating system? 1.4 In the Xinu multi-level hierarchy, can a function in the file system code use a function in the process manager? Can a function in the process manager use a function in the file sys- tem? Explain. 1.5 Explore the system calls available on your favorite operating system, and write a program that uses them. 1.6 Various programming languages have been designed that incorporate OS concepts such as processes and process synchronization primitives. Find an example language, and make a list of the facilities it offers. 1.7 Search the web, and make a list of the major commercial operating systems that are in use. 1.8 Compare the facilities in Linux and Microsoft’s Windows operating systems. Does either one support functionality that is not available in the other? 1.9 The set of functions that an operating system makes available to application programs is known as the Application Program Interface or the system call interface. Choose two ex- ample operating systems, count the functions in the interface that each makes available, and compare the counts. 1.10 Extend the previous exercise by identifying functions that are available in one system but not in the other. Characterize the purpose and importance of the functions. 1.11 How large is an operating system? Choose an example system, and count the lines of source code used for the kernel.
- 42. Chapter Contents 2.1 Introduction, 15 2.2 Programming Models For Multiple Activities, 16 2.3 Operating System Services, 17 2.4 Concurrent Processing Concepts And Terminology, 17 2.5 Distinction Between Sequential And Concurrent Programs, 19 2.6 Multiple Processes Sharing A Single Piece Of Code, 21 2.7 Process Exit And Process Termination, 23 2.8 Shared Memory, Race Conditions, And Synchronization, 24 2.9 Semaphores And Mutual Exclusion, 28 2.10 Type Names Used In Xinu, 30 2.11 Operating System Debugging With Kputc And Kprintf, 31 2.12 Perspective, 32 2.13 Summary, 32
- 44. 2 Concurrent Execution And Operating System Services From an article on a new operating system for the IBM PC: Real concurrency — in which one program actually continues to function while you call up and use another — is more amazing but of small use to the average person. How many programs do you have that take more than a few seconds to perform any task? — New York Times, 25 April 1989 2.1 Introduction This chapter considers the concurrent programming environment that an operating system provides for applications. It describes a model of concurrent execution, and shows why applications that operate concurrently need mechanisms to coordinate and synchronize. It introduces basic concepts, such as processes and semaphores, and ex- plains how applications use such facilities. Instead of describing operating systems abstractly, the chapter uses concrete exam- ples from the Xinu system to illustrate concepts such as concurrency and synchroniza- tion. The chapter contains trivial applications that capture the essence of concurrent ex- ecution in a few lines of code. Later chapters expand the discussion by explaining in detail how an operating system implements each of the facilities described. 15
- 45. 16 Concurrent Execution And Operating System Services Chap. 2 2.2 Programming Models For Multiple Activities Even small computing devices are designed to handle multiple tasks at the same time. For example, while a voice call is connected, a cell phone can display the time of day, accept text messages, and allow the user to adjust the volume. More complex computing systems allow a user to run multiple applications that execute at the same time. The question arises: how should the software in such systems be organized? Three basic approaches can be used: d Synchronous event loop d Asynchronous event handlers d Concurrent execution Synchronous event loop. The term synchronous refers to events that are coordinat- ed. A synchronous event loop uses a single, large iteration to handle coordination. During a given iteration of the loop, the code checks each possible activity and invokes the appropriate handler. Thus, the code has a structure similar to the following: while (1) { /* synchronous loop runs forever */ Update time-of-day clock; if (screen timeout has expired) { turn off the screen; } if (volume button is being pushed) { adjust volume; } if (text message has arrived) { Display notification for user; } ... } Asynchronous event handlers. An asynchronous paradigm is used in systems where the hardware can be configured to invoke a handler for each event. For example, the code to adjust volume might be placed in memory at location 100, and the hardware is configured so that when the volume button is pressed, control transfers to location 100. Similarly, the hardware can be configured so that when a text message arrives, control transfers to location 200, and so on. A programmer writes a separate piece of code for each event, and uses global variables to coordinate the interactions. For exam- ple, if a user presses the mute button, the code associated with the mute event turns off the audio and records the status in a global variable. Later, when the user adjusts the volume, code associated with the volume button checks the global variable, turns on the audio, and changes the global variable to indicate that audio is on.
- 46. Sec. 2.2 Programming Models For Multiple Activities 17 Concurrent execution. The third paradigm used to organize multiple activities is the most significant: software is organized as a set of programs that each operate con- currently. The model is sometimes called run-to-completion because each computation appears to run until it chooses to stop. From a programmer’s point of view, concurrent execution is a delight. Compared to synchronous or asynchronous events, concurrent execution is more powerful, easier to understand, and less error-prone. The next sections describe operating systems that provide the support needed for concurrency, and characterize the concurrent model. Later chapters examine the under- lying operating system mechanisms and functions that enable a concurrent programming model. 2.3 Operating System Services What are the main services that an operating system supplies? Although the de- tails vary from system to system, most systems supply the same basic services. The services (with the chapters of the text that describe them) are: d Support for concurrent execution (5–6) d Facilities for process synchronization (7) d Inter-process communication mechanisms (8 and 11) d Dynamic memory allocation (9) d Management of address spaces and virtual memory (10) d High-level interface for I/ O devices (13–15) d Network and Internet communication (16–17) d A file system and file access facilities (19–21) Concurrent execution is at the heart of an operating system, and we will see that concurrency affects each piece of operating system code. Thus, we begin by examining the facilities an operating system offers for concurrency, and use concurrency to show how an application program invokes services. 2.4 Concurrent Processing Concepts And Terminology Conventional programs are called sequential because a programmer imagines a computer executing the code statement by statement; at any instant, the machine is exe- cuting exactly one statement. Operating systems support an extended view of computa- tion called concurrent processing. Concurrent processing means that multiple computa- tions can proceed “at the same time.” Many questions arise about concurrent processing. It is easy to imagine N in- dependent programs being executed simultaneously by N processors (i.e., N cores), but it is difficult to imagine a set of independent computations proceeding simultaneously
- 47. 18 Concurrent Execution And Operating System Services Chap. 2 on a computer that has fewer than N processing units. Is concurrent computation possi- ble even if a computer has a single core? If multiple computations each proceed simul- taneously, how does the system keep one program from interfering with others? How do the programs cooperate so that only one takes control of an input or output device at a given time? Although many processors do incorporate some amount of parallelism, the most visible form of concurrency, multiple independent applications that execute simultane- ously, is a grand illusion. To create the illusion, an operating system uses a technique, called multitasking or multiprogramming — the operating system switches the available processor(s) among multiple programs, allowing a processor to execute one program for only a few milliseconds before moving on to another. When viewed by a human, the programs all appear to proceed. Multitasking forms the basis of most operating sys- tems. The only exceptions are systems used in basic embedded devices, such as a simplistic remote control used with a television, and safety-critical systems, such as flight avionics and medical device controllers. In such cases, designers use a synchro- nous event loop rather than a multitasking system, either to reduce cost or to guarantee that tight time constraints can be met absolutely. Systems that support multitasking can be divided into two broad categories: d Timesharing d Real-time Timesharing. A timesharing system gives equal priority to all computations, and permits computations to start or terminate at any time. Because they allow computa- tions to be created dynamically, timesharing systems are popular for computers that hu- man users operate. A timesharing system allows a human to leave an email application running and a background application playing music while using a browser to view a web page. The chief characteristic of a timesharing system is that the amount of proc- essing a computation receives is inversely proportional to the load on the system — if N computations are executing, each computation receives approximately 1 / N of the avail- able processor cycles. Thus, as more computations appear, each proceeds at a slower rate. Real-time. Because it is designed to meet performance constraints, a real-time sys- tem does not treat all computations equally. Instead, a real-time system assigns priori- ties to computations, and schedules the processor carefully to ensure that each computa- tion meets its required schedule. The chief characteristic of a real-time system arises from its ability to give the processor to high-priority tasks, even if other tasks are wait- ing. For example, by giving priority to voice transmission, a real-time system in a cell phone can guarantee that the conversation is uninterrupted, even if a user runs an appli- cation to view the weather or an application to play a game. Designers of multitasking systems have used a variety of terms to describe a single computation, including process, task, job, and thread of control. The terms process and job often connote a single computation that is self-contained and isolated from other computations. Typically, a process occupies a separate region of memory, and the operating system prevents a process from accessing the memory that has been assigned
- 48. Sec. 2.4 Concurrent Processing Concepts And Terminology 19 to another process. The term task refers to a process that is declared statically. That is, a programming language allows a programmer to declare a task similar to the way one declares a function. The term thread refers to a type of concurrent process that shares an address space with other threads. Shared memory means that members of the set can exchange information efficiently. Early scientific literature used the term process to refer to concurrent execution in a generic sense; the Unix operating system popularized the idea that each process occupied a separate address space. The Mach system intro- duced a two-level concurrent programming scheme in which the operating system al- lows a user to create one or more processes that each operate in an independent region of memory, and to create multiple threads of control within each process. Linux fol- lows the Mach model. To refer to a Linux-style process, the word Process is written with an uppercase P. Because it is designed for an embedded environment, Xinu permits processes to share an address space. To be precise, we might say that Xinu processes follow a thread model. However, because the term process is widely accepted, we will use it throughout the text to refer generically to a concurrent computation. The next section helps distinguish concurrent execution from sequential execution by examining a few applications. As we will see, the difference plays a central role in operating system design — each piece of an operating system must be built to support concurrent execution. 2.5 Distinction Between Sequential And Concurrent Programs When a programmer creates a conventional (i.e., sequential) program, the program- mer imagines a single processor executing the program step-by-step without interruption or interference. When writing code that will be executed concurrently, however, a pro- grammer must take a different view and imagine multiple computations executing simultaneously. The code inside an operating system provides an excellent example of code that must accommodate concurrency. At any given instant, multiple processes may be executing. In the simplest case, each process executes application code that no other process is executing. However, an operating system designer must plan for a situ- ation in which multiple processes have invoked a single operating system function, or even a case where multiple processes are executing the same instruction. To further complicate matters, the operating system may switch the processor among processes at any time; in a multitasking system, no guarantee can be made about the relative speed at which a given computation will proceed. Designing code to operate correctly in a concurrent environment provides a tough intellectual challenge because a programmer must ensure that all processes perform the intended function correctly, no matter what operating system code they execute or in which order they execute. We will see how the notion of concurrent execution affects each line of code in an operating system. To understand applications in a concurrent environment, consider the Xinu model. When it boots, Xinu creates a single concurrent process that starts running the main pro-
- 49. 20 Concurrent Execution And Operating System Services Chap. 2 gram. The initial process can continue execution by itself, or it can create additional processes. When a new process is created, the original process continues to execute, and the new process executes concurrently. Either the original process or a new process can create additional processes that execute concurrently. As an example, consider the code for a concurrent main program that creates two additional processes. Each of the two new processes sends characters over the console serial device: the first process sends the letter A, and the second sends the letter B. File ex2.c contains the source code, which consists of a main program and two functions, sndA and sndB. / /* * e ex x2 2. .c c - - m ma ai in n, , s sn nd dA A, , s sn nd dB B * */ / # #i in nc cl lu ud de e < <x xi in nu u. .h h> > v vo oi id d s sn nd dA A( (v vo oi id d) ), , s sn nd dB B( (v vo oi id d) ); ; / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * m ma ai in n - - E Ex xa am mp pl le e o of f c cr re ea at ti in ng g p pr ro oc ce es ss se es s i in n X Xi in nu u * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d m ma ai in n( (v vo oi id d) ) { { r re es su um me e( ( c cr re ea at te e( (s sn nd dA A, , 1 10 02 24 4, , 2 20 0, , " "p pr ro oc ce es ss s 1 1" ", , 0 0) ) ) ); ; r re es su um me e( ( c cr re ea at te e( (s sn nd dB B, , 1 10 02 24 4, , 2 20 0, , " "p pr ro oc ce es ss s 2 2" ", , 0 0) ) ) ); ; } } / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * s sn nd dA A - - R Re ep pe ea at te ed dl ly y e em mi it t ’ ’A A’ ’ o on n t th he e c co on ns so ol le e w wi it th ho ou ut t t te er rm mi in na at ti in ng g * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d s sn nd dA A( (v vo oi id d) ) { { w wh hi il le e( ( 1 1 ) ) p pu ut tc c( (C CO ON NS SO OL LE E, , ’ ’A A’ ’) ); ; } } / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * s sn nd dB B - - R Re ep pe ea at te ed dl ly y e em mi it t ’ ’B B’ ’ o on n t th he e c co on ns so ol le e w wi it th ho ou ut t t te er rm mi in na at ti in ng g * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d s sn nd dB B( (v vo oi id d) ) { { w wh hi il le e( ( 1 1 ) ) p pu ut tc c( (C CO ON NS SO OL LE E, , ’ ’B B’ ’) ); ; } }
- 50. Sec. 2.5 Distinction Between Sequential And Concurrent Programs 21 In the code, the main program never calls either function directly. Instead, the main program calls two operating system functions, create and resume. Each call to create forms a new process that will begin executing instructions at the address speci- fied by its first argument. In the example, the first call to create passes the address of function sndA, and the second call passes the address of function sndB.† Thus, the code creates a process to execute sndA and a process to execute sndB. Create establishes a process, leaves the process ready to execute but temporarily suspended, and returns an integer value that is known as a process identifier or process ID. The operating system uses the process ID to identify the newly created process; an application uses the proc- ess ID to reference the process. In the example, the main program passes the ID re- turned by create to resume as an argument. Resume starts (i.e., unsuspends) the proc- ess, allowing the process to begin execution. The distinction between normal function calls and process creation is: A normal function call does not return until the called function com- pletes. Process creation functions create and resume return to the caller immediately after starting a new process, which allows execu- tion of both the existing process and the new process to proceed con- currently. In Xinu, all processes execute concurrently. That is, execution of a given process continues independent of other processes unless a programmer explicitly controls in- teractions among processes. In the example, the first new process executes code in function sndA, sending the letter A continuously, and the second executes code in func- tion sndB, sending the letter B continuously. Because the processes execute concurrent- ly, the output is a mixture of As and Bs. What happens to the main program? Remember that in an operating system, each computation corresponds to a process. Therefore, we should ask, “What happens to the process executing the main program?” Because it has reached the end of the main pro- gram, the process executing the main program exits after the second call to resume. Its exit does not affect the newly created processes — they continue to send As and Bs. A later section describes process termination in more detail. 2.6 Multiple Processes Sharing A Single Piece Of Code The example in file ex2.c shows each process executing a separate function. It is possible, however, for multiple processes to execute the same function. Arranging for processes to share code can be essential in an embedded system that has a small memory. To see an example of processes sharing code, consider the program in file ex3.c. †Other arguments to create specify the stack space needed, a scheduling priority, a name for the process, the count of arguments passed to the process, and (when applicable) the argument values passed to the proc- ess; we will see details later.
- 51. 22 Concurrent Execution And Operating System Services Chap. 2 / /* * e ex x3 3. .c c - - m ma ai in n, , s sn nd dc ch h * */ / # #i in nc cl lu ud de e x xi in nu u. .h h v vo oi id d s sn nd dc ch h( (c ch ha ar r) ); ; / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * m ma ai in n - - E Ex xa am mp pl le e o of f 2 2 p pr ro oc ce es ss se es s e ex xe ec cu ut ti in ng g t th he e s sa am me e c co od de e c co on nc cu ur rr re en nt tl ly y * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d m ma ai in n( (v vo oi id d) ) { { r re es su um me e( ( c cr re ea at te e( (s sn nd dc ch h, , 1 10 02 24 4, , 2 20 0, , s se en nd d A A , , 1 1, , ’ ’A A’ ’) ) ) ); ; r re es su um me e( ( c cr re ea at te e( (s sn nd dc ch h, , 1 10 02 24 4, , 2 20 0, , s se en nd d B B , , 1 1, , ’ ’B B’ ’) ) ) ); ; } } / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * s sn nd dc ch h - - O Ou ut tp pu ut t a a c ch ha ar ra ac ct te er r o on n a a s se er ri ia al l d de ev vi ic ce e i in nd de ef fi in ni it te el ly y * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d s sn nd dc ch h( ( c ch ha ar r c ch h / /* * T Th he e c ch ha ar ra ac ct te er r t to o e em mi it t c co on nt ti in nu uo ou us sl ly y * */ / ) ) { { w wh hi il le e ( ( 1 1 ) ) p pu ut tc c( (C CO ON NS SO OL LE E, , c ch h) ); ; } } As in the previous example, a single process begins executing the main program. The process calls create twice to start two new processes that each execute code from function sndch. The final two arguments in the call to create specify that create will pass one argument to the newly created process and a value for the argument. Thus, the first process receives the character A as an argument, and the second process receives character B. Although they execute the same code, the two processes proceed concurrently without any effect on one another. In particular, each process has its own copy of argu- ments and local variables. Thus, one process emits As, while the other process emits Bs. The key point is: A program consists of code executed by a single process of control. In contrast, concurrent processes are not uniquely associated with a piece of code; multiple processes can execute the same code simul- taneously.
- 52. Sec. 2.6 Multiple Processes Sharing A Single Piece Of Code 23 The examples provide a hint of the difficulty involved in designing an operating system. Not only must each piece be designed to operate correctly by itself, the designer must also guarantee that multiple processes can execute a given piece of code concurrently without interfering with one another. Although processes can share code and global variables, each process must have a private copy of local variables. To understand why, consider the chaos that would result if all processes shared every variable. If two processes tried to use a shared vari- able as the index of a for loop, for example, one process might change the value while another process was in the midst of executing the loop. To avoid such interference, the operating system creates an independent set of local variables for each process. Function create also allocates an independent set of arguments for each process, as the example in file ex3.c demonstrates. In the call to create, the last two arguments specify a count of values that follow (1 in the example), and the value that the operating system passes to the newly created process. In the code, the first new process has char- acter A as an argument, and the process begins execution with formal parameter ch set to A. The second new process begins with ch set to B. Thus, the output contains a mixture of both letters. The example points out a significant difference between the sequential and concurrent programming models. Storage for local variables, function arguments, and a function call stack is associated with the process executing a function, not with the code for the function. The important point is: an operating system must allocate additional storage for each process, even if the process shares the same code that another process or processes are using. As a consequence, the amount of memory available limits the number of processes that can be created. 2.7 Process Exit And Process Termination The example in file ex3.c consists of a concurrent program with three processes: the initial process and the two processes that were started with the system call create. Recall that when it reaches the end of the code in the main program, the initial process ceases execution. We use the term process exit to describe the situation. Each process begins execution at the start of a function. A process can exit by reaching the end of the function or by executing a return statement in the function in which it starts. Once a process exits, it disappears from the system; there is simply one less computation in progress. Process exit should not be confused with normal function call and return or with recursive function calls. Like a sequential program, each process has its own stack of function calls. Whenever it executes a call, an activation record for the called function is pushed onto the stack. Whenever it returns, a function’s activation record is popped
- 53. 24 Concurrent Execution And Operating System Services Chap. 2 off the stack. Process exit occurs only when the process pops the last activation record (the one that corresponds to the top-level function in which the process started) off its stack. The system routine kill provides a mechanism to terminate a process without wait- ing for the process to exit. In a sense, kill is the inverse of create — kill takes a process ID as an argument, and removes the specified process immediately. A process can be killed at any time and at any level of function nesting. When terminated, the process ceases execution and local variables that have been allocated to the process disappear; in fact, the entire stack of functions for the process is removed. A process can exit by killing itself as easily as it can kill another process. To do so, the process uses system call getpid to obtain its own process ID, and then uses kill to request termination: kill( getpid() ); When used to terminate the current process, the call to kill never returns because the calling process exits. 2.8 Shared Memory, Race Conditions, And Synchronization In Xinu, each process has its own copy of local variables, function arguments, and function calls, but all processes share the set of global (external) variables. Sharing data is sometimes convenient, but it can be dangerous, especially for programmers who are unaccustomed to writing concurrent programs. For example, consider two concurrent processes that each increment a shared integer, n. In terms of the underlying hardware, incrementing an integer requires three steps: d Load the value from variable n in memory into a register d Increment the value in the register d Store the value from the register back into the memory location for n Because the operating system can choose to switch from one process to another at any time, a potential race condition exists in which two processes attempt to increment n at the same time. Process 1 might start first and load the value of n into a register. But just at that moment, the operating system switches to process 2, which loads n, in- crements the register, and stores the result. Unfortunately, when the operating system switches back to process 1, execution resumes with the original value of n in a register. Process 1 increments the original value of n and stores the result to memory, overwrit- ing the value that process 2 placed in memory. To see how sharing works, consider the code in file ex4.c. The file contains code for two processes that communicate through a shared integer, n†. One process repeat- edly increments the value of the shared integer, while the other process repeatedly prints the value. †The code uses the type name int32 to emphasize that variable n is a 32-bit integer; a later section ex- plains conventions for type names.
- 54. Sec. 2.8 Shared Memory, Race Conditions, And Synchronization 25 / /* * e ex x4 4. .c c - - m ma ai in n, , p pr ro od du uc ce e, , c co on ns su um me e * */ / # #i in nc cl lu ud de e x xi in nu u. .h h v vo oi id d p pr ro od du uc ce e( (v vo oi id d) ), , c co on ns su um me e( (v vo oi id d) ); ; i in nt t3 32 2 n n = = 0 0; ; / /* * G Gl lo ob ba al l v va ar ri ia ab bl le es s a ar re e s sh ha ar re ed d b by y a al ll l p pr ro oc ce es ss se es s * */ / / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * m ma ai in n - - E Ex xa am mp pl le e o of f u un ns sy yn nc ch hr ro on ni iz ze ed d p pr ro od du uc ce er r a an nd d c co on ns su um me er r p pr ro oc ce es ss se es s * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d m ma ai in n( (v vo oi id d) ) { { r re es su um me e( ( c cr re ea at te e( (c co on ns su um me e, , 1 10 02 24 4, , 2 20 0, , c co on ns s , , 0 0) ) ) ); ; r re es su um me e( ( c cr re ea at te e( (p pr ro od du uc ce e, , 1 10 02 24 4, , 2 20 0, , p pr ro od d , , 0 0) ) ) ); ; } } / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * p pr ro od du uc ce e - - I In nc cr re em me en nt t n n 2 20 00 00 0 t ti im me es s a an nd d e ex xi it t * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d p pr ro od du uc ce e( (v vo oi id d) ) { { i in nt t3 32 2 i i; ; f fo or r( ( i i= =1 1 ; ; i i = =2 20 00 00 0 ; ; i i+ ++ + ) ) n n+ ++ +; ; } } / /* *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * * c co on ns su um me e - - P Pr ri in nt t n n 2 20 00 00 0 t ti im me es s a an nd d e ex xi it t * *- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - * */ / v vo oi id d c co on ns su um me e( (v vo oi id d) ) { { i in nt t3 32 2 i i; ; f fo or r( ( i i= =1 1 ; ; i i = =2 20 00 00 0 ; ; i i+ ++ + ) ) p pr ri in nt tf f( ( T Th he e v va al lu ue e o of f n n i is s % %d d n n , , n n) ); ; } } In the code, global variable n is a shared integer that is initialized to zero. The process executing produce iterates 2000 times, incrementing n; we call the process the
- 55. Exploring the Variety of Random Documents with Different Content
- 56. That feverish agitation, noise, and glaring sunlight introduced us suddenly to new and violent sensations. Already at Gibraltar, Metchnikoff had made arrangements with a Spanish-speaking Arab from Tangiers who undertook our installation. He provided us with a very primitive dwelling, himself serving as our guide, cook, and general factotum. We hastened to look for zoological material: alas, the sea was almost a desert. After a long search we only found a few rare sea- urchins, and Metchnikoff had to content himself with this meagre fauna during the whole of the winter. He resigned himself to the study of the embryology of sea-urchins in order to fill a few lacunæ in his previous researches. As he could not work much for lack of materials, he came with us for long excursions, during which he used to improvise interminable and very amusing tales with which to entertain my little sister. At the beginning of our stay we were greatly interested by the life and customs of the country. The picturesque and varied crowd, the dignified and biblical types of Arabs, the bronzed Berbers, negroes, fanatical sects of Aïssawas, snake-charmers, the jousts, and mad races of cavalry across the sandy beach; opium smokers; mysterious silhouettes of veiled women; the call to prayer from the tall minarets —all that strange and exotic life fascinated us. But after a time the wild customs, continual shouting on the occasion of every ceremony, vendettas, cruel fanaticism, and also the absolute lack of intellectual resources, began to tell on our nerves. Inactivity weighed heavily upon Metchnikoff; nevertheless, he bore his ill-luck with his usual courage and gaiety, finding great consolation in the excellent influence that the climate of Tangiers had upon all our healths. At last, in the spring, we started for Villefranche, where he immediately set to work with success upon the embryology of jelly- fish; an important monograph on that subject was published by him in 1886. In it he gave definite form to his theory of the phagocytella and the genetic relationships of animals and of their primitive organs, a theory already mentioned above (p. 110).
- 57. From Villefranche we went to Trieste, where Metchnikoff studied star-fish and filled the lacunæ in his researches on the origin of the mesoderm. In a medical review which he read at Trieste, he found the first account of his phagocyte theory; it was an unfavourable and hostile criticism by a German scientist of the name of Baumgarten, endeavouring to prove that Metchnikoff’s deductions were inadmissible. This grieved and pained him very much, but he immediately recovered himself and strongly determined to study the medical side of the question in order to prove on that ground that his theory was well-founded.
- 58. CHAPTER XX A Bacteriological Institute in Odessa — Unsatisfactory conditions — Experiments on erysipelas and on relapsing fever. The results of Pasteur’s antirabic inoculations were published in 1885. The Municipality of Odessa, desirous of founding a bacteriological station in that town, sent Dr. Gamaléia to Paris to study the new method. Metchnikoff was appointed Scientific Director of the new institution, and Drs. Gamaléia and Bardach, former pupils of his, were entrusted with the preparation of vaccines and preventive inoculations. The Institute, opened in 1886, was founded at the expense of the Municipality of Odessa and of the Zemstvo of the Kherson Province. Metchnikoff himself describes as follows the short time he spent in that Institute: ... Having given up my State work, I placed myself at the service of the city and the Zemstvo. Absorbed as I was by the scientific part of the work, I confided to my young colleagues the practical part, i.e. the vaccinations and the perfection of vaccines. It was to be supposed that all would go very well. Work in the new Institute began with ardour. But, very soon, a strong opposition manifested itself against it. The medical administration began to make incursions into the Institute, with a view to finding some infractions of the regulations.
- 59. Medical society was hostile to every work which issued from the laboratory. The institutions which had subscribed funds for the Institute were demanding practical results, while all necessary work towards that object was met by every sort of obstacle. For instance, in order to destroy certain voles, very harmful to the cereals of Southern Russia, we proposed to make experiments as to infecting those rodents with the microbe of chicken cholera. Laboratory experiments were begun with that object. But, one day, I received an order from the Prefect peremptorily forbidding those experiments. This measure had been taken at the instigation of local physicians; having seen in a Petersburg newspaper an article by some one who had not a notion of bacteriology, they had assured the Prefect that chicken cholera could turn into Asiatic cholera. I had to appeal to the General Governor, who ended by countermanding the Prefect’s order; nevertheless this incident was not without regrettable consequences concerning the ulterior activities of the Institute. Apart from all that, a deep scission took place between the members, though they were so few, of the Institute itself, and this had fatal consequences. The men who were in charge of the practical work ceased to work in concert; I could not take their place, being overwhelmed with scientific researches, besides which, holding no medical degree, I was not qualified to perform vaccinations on human beings. Under those conditions, I understood that in my quality as a theoretician, I should do well to retire, leaving the laboratory to practitioners who, bearing full responsibility, would fill the part better. During his stay at the Odessa Bacteriological Institute, Metchnikoff had busied himself with infectious diseases in order to answer the first objections to his theory. He began by the microbes of erysipelas and showed that the phenomena of the disease, as well as those of recovery, were in full accord with the postulates of the phagocyte theory. And then he studied relapsing fever in order to answer Baumgarten’s objections, affirming that there was no phagocytic reaction in that disease, though it almost invariably ended in recovery. Experiments on man not being possible, Metchnikoff procured some monkeys, which he inoculated with relapsing fever, and ascertained that
- 60. Baumgarten’s error was due to the fact that he had only looked for phagocytosis in the patient’s blood, whilst it really took place in the spleen. These researches on erysipelas and relapsing fever were published in Virchow’s Archives in 1887. Besides this scientific work, he was also giving lectures on bacteriology to some physicians, and was in full productive activity when external opposition and the discord among his collaborators in the Institute itself forced upon him the conviction that he could remain there no longer. At that very moment the Prince of Oldenburg, having founded a Bacteriological Institute at Petersburg, invited Metchnikoff to take charge of it. He had to refuse, fearing the Northern climate for my health, and knowing from experience that it was impossible for a layman to manage an Institute with a medical staff. Yet he could not do without a laboratory. Seeing no possibility of having one in Russia, he decided to look abroad for a refuge and a laboratory. “Having learnt from experience at Odessa,” he wrote, “how difficult was the struggle against an opposition coming from all sides and devoid of reasonable causes, I preferred to go abroad to look for a peaceful shelter for my scientific researches.” We were no longer held back by family considerations; our links with Russia had gradually loosened. He had resigned from the University, discord reigned at the Odessa Bacteriological Institute, conditions of life in Russia were very unfavourable to scientific activity; in a word, “obstacles from above, from below, and from all sides,”—as Metchnikoff expressed it,—gradually led to his resolution to leave his native country.
- 62. CHAPTER XXI Hygiene Congress in Vienna — Wiesbaden — Munich — Paris and Pasteur — Berlin and Koch — Failure of anthrax vaccination of sheep — Decision to leave Russia. In 1887 we went to Vienna, where a Congress of Hygienists was held, in which, for the first time, bacteriologists took part. Metchnikoff thus had the opportunity of becoming acquainted with many of them and to make inquiries concerning bacteriological laboratories. Professor Hueppe, of Wiesbaden, very kindly invited him to come to work in his own. The idea pleased Metchnikoff, who thought that a peaceful little University town would be very favourable to his work. But he found that his situation would be very difficult at Wiesbaden on account of the lack of harmony between the different laboratories in the town; he therefore gave up the project which had seemed to him so tempting. By this time many objections had been raised against the phagocyte theory, and, Emmerich having attacked him very violently, Metchnikoff went to Munich to have an explanation with him. This gave him the opportunity of realising that Munich, like Wiesbaden, was not a place where he would care to settle. He had a great desire to know Pasteur and his collaborators, who had just been playing such an important scientific part, and, finding ourselves within easy reach of Paris, we repaired thither, without the
- 63. slightest idea of settling there. This is how Metchnikoff himself described his first interview with Pasteur: On arriving at the laboratory destined for the antirabic vaccinations, I saw an old man, rather undersized, with a left hemiplegia, very piercing grey eyes, a short beard and moustache and slightly grey hair, covered by a black skull-cap. His pale and sickly complexion and tired look betokened a man who was not likely to live many more years. He received me very kindly, and immediately spoke to me of the question which interested me most, the struggle of the organism against microbes. “I at once placed myself on your side,” he told me, “for I have for many years been struck by the struggle between the divers micro-organisms which I have had occasion to observe. I believe you are on the right road.” Pasteur at that time was chiefly occupied with antirabic vaccinations and with the building of a new Institute in the rue Dutot. Seeing the vast dimensions of the edifice and learning that the scientific staff was not large, Metchnikoff asked Pasteur if he might hope to work in one of the laboratories in an honorary capacity. Pasteur not only acceded to this request but offered him a whole laboratory. He was most kind, invited us to his home and introduced Metchnikoff to his collaborators, who produced an excellent impression on my husband. Though all this made him incline more and more towards the Pasteur Institute, he still dreaded life in a large and noisy city, thinking that a peaceful little University town would be more favourable to his work. Therefore, before making a final decision, he desired to visit a few more bacteriological laboratories. On our way back we passed through Berlin, where Metchnikoff wished to see Professor Koch and to show him some interesting specimens of phagocytosis. The great savant received him very coldly. For a long time, while examining specimens of the spleen in relapsing fever, he refused to recognise in them an example of phagocytosis. Though he was at last obliged to bow to evidence, he yet remained unfavourable to the phagocyte theory, and all his assistants followed his example. Metchnikoff was much surprised
- 64. and grieved by this hostility towards his ideas, notwithstanding that they were based on well-established facts. We hastened to leave Berlin. Many years later, when phagocytosis was generally admitted, even in Germany, Professor Koch and many other German scientists welcomed Metchnikoff very kindly, which somewhat counterbalanced the unpleasantness of early memories. But, at that time, the contrast between our impression of Paris and of Germany was so great that all hesitation was at an end: the choice was made. On returning to Odessa, Metchnikoff began to prepare his resignation and his departure. Yet he still had time to make some researches on phagocytosis in tuberculosis, in reply to the objections which rained upon his theory. In the spring, he handed over the direction of the Institute to Dr. Gamaléia and took leave; we went to the country for a while before our final departure. During that time, Drs. Gamaléia and Bardach were making anthrax vaccinations on a large scale in a vast private property in the province of Kherson. When we were settled in our country home, Metchnikoff received a telegram announcing that the first anthrax vaccine had killed many thousand sheep. Though, as a matter of fact, his personal responsibility was not involved, the blow was a terrible one; he hastened back to Odessa to elucidate the cause of the catastrophe. But it remained obscure.... This painful episode was the last drop which made the cup brim over; it strengthened Metchnikoff in his resolve to leave Russia.
- 65. CHAPTER XXII The Pasteur Institute — Dreams realised — Metchnikoff at fifty — Growing optimism — Attenuated sensitiveness — The Sèvres villa — Daily routine. Having decided to settle in France, we hastened to make ourselves acquainted with contemporary French literature, thinking to find in it a reflection of the soul and manners of the nation. But the realistic literature of the time, in spite of the great artistic worth of many of the authors, gave us an erroneous idea of life in France, of which it represented but one of many aspects. It was therefore with apprehension that we asked ourselves if we should ever be able to adapt ourselves to the new conditions, and whether our isolation would not be great. We arrived in Paris on the 15th of October 1888, and we lodged at a small hotel in the Latin quarter, not far from the rue d’Ulm where the old Pasteur Institute stood, the new one not being completed. There was but little room in the laboratory, and Metchnikoff felt rather uneasy, fearing that he was in the way. But the new Institute soon was sufficiently advanced for him to settle there. He was given two rooms on the second floor; I served as his assistant; he was perfectly happy at being at last able to give himself up in peace to his work. Soon, young physicians came to work under his direction. Their number having increased, he was given a whole floor in which to instal them, two rooms on that floor
- 66. being reserved for his own use. He occupied these rooms until the end of his life. His dreams were at last realised. This is from a narration of the causes which led to his departure from Russia, in his own words: Thus it was in Paris that I succeeded at last in practising pure Science apart from all politics or any public function. That dream could not have been realised in Russia because of obstacles from above, from below, and from all sides. One might think that the hour of science in Russia has not yet struck. I do not believe that. I think, on the contrary, that scientific work is indispensable to Russia, and I wish from my heart that future conditions may become more favourable than in the time of which I have spoken in the above lines. Soon he was able to appreciate the great French qualities: humanitarian manners, tolerance, and gentleness, real freedom of thought, loyal and courteous intercourse, all of which made life easy and agreeable. And most precious of all were the true friendships which he contracted with his colleagues and his pupils. Indeed the Institut Pasteur and France became for him a second Motherland, and when in later years he was invited to other countries with more liberal conditions, he habitually replied that only for one place would he leave the Pasteur Institute, “the neighbouring cemetery of Montparnasse.” However, after his death, the Pasteur Institute which he had so loved continued to give him hospitality and harboured his ashes.... Pasteur himself ever was most kind and helpful to Metchnikoff. During the first years, when his health still allowed it, he used often to come to the laboratory, questioning Metchnikoff on his researches with much interest and always warmly encouraging him. He even attended assiduously his course of lectures on inflammation. After his state of health no longer allowed him to go out, Metchnikoff used to visit him every day, and tried to cheer him by talking to him of current researches. MM. Duclaux and Roux became his closest friends; they were at first brought together by scientific interests and by questions concerning
- 67. the Institute; but, gradually, personal sympathy grew up between them, binding them by that solid bond which is made up of daily occurrences, inducing respect, confidence, and affection. Moreover, Metchnikoff felt the deepest gratitude towards Pasteur and his collaborators, who had given him the possibility of working in so favourable an atmosphere. From the very first, Pasteur sympathised with the phagocyte theory; the other members of the Institute thought it too biological, almost vitalistic. But when they had made themselves thoroughly cognisant with it, they also adopted it. Thus, having found in the Pasteur Institute not only favourable working conditions but also moral support, Metchnikoff became deeply attached to it, and the interests of “the House” became his. In 1915, on the occasion of Metchnikoff’s seventieth anniversary, M. Roux, in a Jubilee speech, gave of him and of his work the following appreciation which describes, better than anything I could say, what his part was in the Pasteur Institute: In Paris as in Petrograd, as in Odessa, you have become a leader of thought, and you have kindled in this Institute a scientific focus which has radiated afar. Your laboratory is more alive than any in the house; workers come to it in crowds. There, the bacteriological events of the day are discussed, interesting preparations examined, ideas sought for that may help an experimenter to solve difficulties in which he has become involved. It is to you that one comes to ask for a control experiment on a newly observed fact, for a criticism of a discovery that does not always survive the test. Moreover, as you read everything, every one comes to you for information, for an account of a newly published memoir which there is no time to read. It is much more convenient than to consult the library and also much safer, for errors of translation and interpretation are avoided. Your erudition is so vast and so accurate that it is made use of by the whole house. How many times have I not availed myself of it? One never fears to take advantage of it, for no scientific question ever finds you
- 68. indifferent. Your ardour warms the indolent and gives confidence to the sceptical. You are an incomparable collaborator as I know, I who have had the good fortune of being associated with your researches on several occasions. Indeed, you did nearly all the work! More even than your science, your kindliness attracts; who amongst us has not experienced it? I have had a touching proof of it when, many times, you have nursed me as if I were your own child. You are so happy in doing good that you even feel gratitude towards those whom you serve. This is such an intimate gathering that I may be allowed to say quite openly that it is so painful to you not to give that you prefer being exploited rather than close your hand. The Pasteur Institute owes you much; you have brought to it the prestige of your renown, and by your work and that of your pupils you have greatly contributed to its glory. You have given a noble example of disinterestedness by refusing any salary in those years when the budget was balanced with difficulty and by preferring to the glorious and lucrative situations that were offered to you the modest life of this house. Still a Russian by nationality, you have become French by your choice, and you contracted a Franco-Russian alliance with the Pasteur Institute long before the diplomats thought of it. At the beginning the members of the Pasteur Institute were few, and the association bore a quasi-family character, Pasteurians often being compared with a monastic order, united by the worship of science. The progressive growth of the Institute inevitably destroyed its character of intimacy, but it remained a precious scientific focus, and this is what Metchnikoff said of it in 1913, à propos of the twenty-fifth anniversary of its foundation: If we weigh the for and against of the Pasteur Institute, it is indisputable that the first surpasses the second by a great deal. I do not think another institution exists that is equally favourable to work. Innumerable proofs have been adduced to attest this in the twenty-five years that our House has existed. It was especially the development of pure scientific research in the Institute which interested Metchnikoff; he continually considered means of contributing towards it; he thought it necessary to attract
- 69. active scientific forces regardless of their origin, to institute generous scientific “scholarships,” and to stimulate by every means scientific activity and spirit. As the rapid development of bacteriology necessitated having recourse to chemistry, physics, and physiology, he considered it indispensable to organise collective work in which specialists in these divers branches should take part, thus collaborating to the solution of the same problem. Later he was able to realise this project, up to a certain point, in his own laboratory, when studying intestinal flora. He thought it would be useful to extend this method, as far as possible, to researches such as that on tuberculosis and on cancer, such researches being complicated and protracted and demanding co-ordinate efforts and an organisation that should prevent the repetition of individual first steps. A clinic attached to the Pasteur Institute and adapted to scientific researches seemed to him indispensable. He also considered that the experimental study of those human diseases which can only be inoculated in anthropoid apes should be carried out through the breeding of those animals in the colonies, for infantile diseases demand very young apes as subjects for experiments, and they cannot be brought to Europe in sufficient numbers without great loss. A mission of workers might carry out experiments on the spot. He thought the popularisation of science a very useful thing and wished the Pasteur Institute to participate in it by appropriate courses of public lectures. He attached great importance to the penetration into ordinary life of results acquired by science, for the struggle against disease consists chiefly in prophylactic and hygienic measures which can only be applied by a well-informed public. For that reason he was always willing to be interviewed on scientific questions by journalists and, indeed, by any one, however ignorant. In order to instruct the public he often wrote popular articles on questions of hygiene and medicine.
- 70. Science in general never was a dead letter for him; his most abstract conceptions were always narrowly bound to life; he saw one through the other and considered that they should serve each other. Apart from scientific researches, he took part in the courses given at the Pasteur Institute. He prepared his lectures with infinite care, and, in spite of his long experience, he never could give them without some nervousness, especially during the last years of his life. He used even to write down the first sentences and to read them out in order to give himself time to recover; but very soon his self-control would return, and he would proceed with animation and lucidity; his lectures were living and suggestive. I have mentioned above Roux’s masterly appreciation of his influence at the Pasteur Institute. The following was written to me, a year after Metchnikoff’s death, by one of his closest disciples and collaborators, and describes in a vivid manner the deep feelings with which he inspired his pupils: You say that you love to think that he continues to live in others. Could it have been otherwise? A character as powerful as his is capable of influencing and illuminating the life, not of one individual, but of a whole generation. I look upon it as the greatest good fortune of my life that I was able to spend my best years in his orbit and to impregnate my mind with his spirit, not his scientific spirit, but that which he manifested in facing life and humanity. “This bond has become so much part of myself that my first impulse is always to act in the way he would have approved. I even feel the need to share with others what I received from him. I do not know whether it will be given to me to solve certain problems posed by him, but I have the conviction that his spirit, in its purity, will be preserved among us. He will ever live in those who worked by his side, and in those who will come to work in his laboratory. It cannot be otherwise.” Metchnikoff on his part never remained indifferent to his pupils. His solicitude towards them was warm, sometimes paternal, always ready and active. Many of his pupils remained his friends and collaborators for years afterwards. His fiery and exclusive temperament, however, made him take up a very different attitude in exceptional cases, when he found himself in front of one who
- 71. persisted in a path which Metchnikoff himself considered the wrong path, or before an action which he thought disloyal or work done without conscience. Then he became beside himself, and positively dangerous to those who had exposed themselves to the paroxysm of his indignation. Fortunately such cases were rare; as a general rule, the atmosphere of his laboratory was impregnated with scientific spirit and ardour; all forces in it converged towards the same goal, being bound together by a community of aspirations and activity of which he was the soul. The first period of his life in France was taken up by the strengthening and development of the phagocyte theory and by an eager struggle in its defence. He displayed in it his full energy as a scientist and a fighter, and this was perhaps the most agitated, the most tense period of his life. When at last his theory was securely established and began to be accepted, he continued his researches with the same passionate ardour but in an atmosphere of peace. It was joy and bliss to him to be able to work apart from other preoccupations, and the years of his life between fifty and sixty were the happiest he ever had. The state of his soul and his ideas had considerably evolved in the course of years; the great moral and physical sensitiveness which had so often made him miserable in his youth had decreased and he had become much less impulsive. Unpleasant sensations no longer caused him so much suffering; he could bear the mewing of a cat or the barking of a dog; personal vexations no longer made him take such a horror of life as to wish to be rid of it: he now merely tried to conquer them. At first this change operated less upon his ideas than upon his sensations and sentiments. Accustomed as he was to analyse his
- 72. emotions, he realised the development within himself of a new sense of appreciation; less sensitive now to extreme impressions, he had become more so to ordinary ones. For instance, though less enchanted by music, and less irritated by discordant noises, he enjoyed absolute calm more fully. Now indifferent to rich food, which he formerly used to enjoy, he appreciated simple fare, bread and pure water. He did not seek for picturesque sites but took infinite pleasure in watching the growth of grass or the bursting of a bud. The first halting steps or the smile of an infant charmed and delighted him. Demanding less from life, he now appreciated it as it was, and experienced the joy of mere living. The instinct, the sense of life had been born in him. He now saw Life and Nature under a different aspect from that which they had borne for him in his youth, for he had gradually acquired more balance; he had become adapted. In their turn, his ideas evolved towards a more optimistic conception of life. His reflections, freed from the yoke of his juvenile sensitiveness, tended towards the possibility of a correction of the disharmonies of human nature through knowledge and will. This evolution had taken years. “In order to understand the meaning of life,” he said, “it is necessary to live a long time, without which one finds oneself in the position of a congenitally blind man before whom the beauties of colour are spread out.” During the twenty-eight years that he lived in France, nearly all his time was devoted to the laboratory. Whilst the Institute was still in its beginning, work there was calm and collected; but, as its growing renown attracted many people, this quietude decreased considerably. Metchnikoff felt this, but could not bring himself to refuse to admit those who came; he compensated himself by peaceful Sundays and holidays.
- 73. For a long time we inhabited the neighbourhood of the Institute and spent the summers at Sèvres; in 1898 we bought a small villa there with a sum of money which we inherited from an aunt. In 1905 we settled there altogether, for Metchnikoff, confined in the laboratory all day, felt the need of fresh air; the daily walk that he was obliged to take to reach the house and the absolute calm, away from the noise of the city, suited him; he even fancied that the hill on which the house was built provided him with a wholesome exercise for his heart. The return to Sèvres, which he greatly liked, was to him a daily source of pleasure. I can see him now, hastily coming out of the train, his pockets full of papers and brochures which he read in the train and parcels in his hands, for he loved to bring home little presents. A kindly smile illumined his face and he never failed to express the pleasure he felt at coming home. “How pure the air is! How green the grass! What peace! You see, if I did not go to Paris to work I should not be so alive to the charm of Sèvres and the pleasure of rest.” He used to come home at seven and do no more work; it was his daily rest. He then gave himself up to complete relaxation, joked, related the incidents of the day, spoke of his researches, planned experiments for the next day, read aloud part of the evening and then listened to music, not only because he liked it, but also because he wanted to “switch on to another line,” i.e. rest his mind completely. He was an incomparable companion, always alive and communicative, generously giving out the treasures of his heart and his intelligence. He liked a simple life; all artifice, all convention displeased him. He disliked luxury in his person to that extent that he never consented to possess a gold watch nor any object with no particular use. His only luxury was to gratify others. He enjoyed peaceful family life and a circle of intimate friends. Yet, appreciating as he did all serious manifestations of life, he was glad to have the opportunity of meeting people who were interesting either in themselves or for the knowledge which they could impart.
- 74. In Life as in Science he found precepts to help the evolution of his moral and philosophical ideas, which he placed in their turn at Life’s service. If he could not solve a problem, he at least pointed out its importance. His attentive penetration of things in themselves, coupled with a creative imagination, was the force which enabled him to open out new prospects and new paths. On looking back upon his own life, he used to say that the period spent at the Pasteur Institute had been the happiest, the most favourable to his scientific work; he therefore remained deeply attached to it until the end of his life.
- 75. CHAPTER XXIII Opposition to the phagocyte theory — Scientific controversies — Experiments in support of the phagocyte theory — Behring and antitoxins — The London Congress — Inflammation. As long as Metchnikoff was but a zoologist, the scientific atmosphere around him remained calm and serene. But everything changed suddenly when he entered the domain of pathology with his theory of phagocytes and phagocytosis. Here was the realm of secular traditions, deeply rooted, and of theories generally admitted but resting on no biological basis. Attacks and objections against his theories came following upon each other with a rush, only to be compared with the racing clouds of a stormy sky or the hurrying waves of a tempestuous sea. An epic struggle began for Metchnikoff which was to last for twenty-five years, until the moment when the phagocyte theory, his child now grown up, emerged victoriously. To each attack, to each objection, he answered by fresh experiments, fresh observations annihilating objections; his theory was assuming a wider and wider scope, becoming more solid, more convincing.... But only his intimates knew how much the struggle cost him in vital force, what sleepless nights, due to continuous cerebral tension and to the effort to conceive some new and irrefragable experiment, what alternations of hope and depression.... In an ardent, stormy life such as this, each year counted for many.
- 76. As soon as he arrived at the Pasteur Institute he undertook active researches with the object of developing and defending the phagocyte theory. By experiments on the rouget of pigs he refuted the objections of Emmerich, who affirmed that, in that disease, the destruction of the microbes was not due to phagocytes. By experiments on the anthrax of pigeons he answered the attacks of Baumgarten and his pupils. To Behring, who affirmed that immunity was due to the bactericidal power of the serum, he replied by a series of experiments on the anthrax of rats. By all these researches Metchnikoff proved that recovery and immunity depended on the absorption and digestion of living, virulent microbes by phagocytes. Natural or artificial vaccination by attenuated microbes allows the phagocytes to become gradually accustomed to digest more virulent ones, and this confers immunity upon the organism. That phenomenon is comparable to that by which we can accustom ourselves gradually to doses of poison which would be very harmful if taken at the start (arsenic, opium, nicotine, etc.). Little by little, the accuracy of Metchnikoff’s observations began to be realised, and, moreover, other scientists supported him by their personal investigations. The part played by phagocytosis was becoming more and more evident and the question was ripening in France and in England, but in Germany it still met with great opposition. At the Berlin Congress in 1890 the theory was received very favourably by Lister, whilst Koch attacked it, trying to prove that phagocytes played no part in immunity, which, according to him, depended upon the chemical properties of the blood. Soon after that, Behring discovered antitoxins, and this seemed to favour the chemical or humoral theory of immunity. According to the latter, microbes and their poisons were rendered harmless by the
- 77. chemical properties of the blood serum, properties similar to those of disinfecting substances. In spite of his firm conviction of the solidity of the phagocyte theory, this discovery was a shock to Metchnikoff, for it was in apparent contradiction with the cellular theory of immunity. He hastened to undertake a series of researches; his overflowing eagerness infected his whole circle, every one taking the warmest interest in the progress of his experiments. This was just as preparations were being made to take part in the London Congress, where the question of immunity was to be debated and had indeed been placed at the head of the programme. Many papers were being prepared, and a veritable tourney of opinions was to take place at this Congress. Metchnikoff had already been to England once, in the spring of 1891, on the occasion of his reception as an Honorary Doctor by the University of Cambridge. This gave him the opportunity of making closer acquaintance with the English, who inspired him with great sympathy; years only increased this feeling. He appreciated the originality of their earnest and generalising spirit, their loyalty and energy; he was grateful to them for the attentive and favourable attitude with which his scientific work and himself had been received. He was therefore delighted that this Congress, which was to be the scene of his final struggle against his contradictors, should take place in England and not in Germany, a country hostile to his ideas. In view of the importance of the coming debate, a series of fresh experiments was made. This time Metchnikoff undertook them not only in person, but also in collaboration with M. Roux and with some students. The whole laboratory was in a state of effervescence. The principal papers to be read at the Congress on the question of immunity were those of Messrs. Roux and Büchner, the first entirely in favour of the phagocyte theory and the second supporting the humoral theory.
- 78. Metchnikoff read an epitome of his researches and of his answers to attacks on his theory. Towards the end of the Congress the latter had visibly acquired the suffrage of numerous scientists. Roux wrote to me from London concerning my husband’s paper: Metchnikoff is busy showing his preparations and, besides, he would not tell you how great is his triumph. He spoke with such passion that he carried everybody with him. I believe that, this evening, the phagocyte theory is the richer by many friends. Thus the researches made in recent years and the results of the London Congress allowed us to consider the phagocyte theory of immunity as being solidly established. Yet, Behring’s discovery of antitoxins still hung over it like a sword of Damocles; it was imperative that the respective parts played by antitoxins and by phagocytes should be elucidated. With that object in view, Metchnikoff undertook new researches and succeeded in ascertaining once for all the narrow link between immunity and the function of the phagocytes which probably elaborate the antitoxins as a product of their digestion of vaccinal toxins. He drew this conclusion from the fact that, in a rabbit vaccinated against hog- cholera, the exudate devoid of phagocytes[20] is neither bactericidal, nor antitoxic, nor attenuating, while it is so if it contains phagocytes. Therefore a relation of causality exists between cells and the acquired properties of humors. And the resistance of the animal is in visible correlation with the degree of phagocytosis which is manifested by it. These results having been established, it seemed as if the last rampart of the humoral theory had been taken by storm. In the meanwhile the persistent and bitter opposition of physicians to the phagocyte theory made a great impression on Metchnikoff, and, while stimulating his energy in defence of his ideas, it maintained him in a state of nervous excitement and even depressed him.
- 79. He asked himself why this obstinate opposition to a doctrine based on well-established facts, easily tested and observed throughout the whole animal kingdom? To him, a naturalist, it seemed clear and simple and all the more admissible that it was confirmed by the generality of its application to all living beings. But, he thought, perhaps the real cause of the attitude of the contradictors lies in the very fact that medical science only concerns itself with the pathological phenomena of higher animals, leaving their evolution entirely out of account, as well as their starting-point in lower animals—whilst it is the very simplicity of the latter which allows us to penetrate to the origin of the phenomena. Perhaps a general plan of the whole, in the shape of a comparative study, embracing the whole animal scale, would throw light over the generality of phagocytic phenomena and would make their continuity understood through normal and pathological biology. He determined to make this effort. In order to place in a fresh light the biological evolution of phagocytosis phenomena in disease, he chose one of the principal manifestations of pathological phagocytosis, inflammation, and, in 1891, gave a series of lectures on this subject which he afterwards published in a volume. According to his usual method, he began by the most primitive beings, taking as a starting- point the lower organisms which do not yet possess differentiated functions, and whose normal digestion is, if necessary, used as a means of defence against noxious agents. Then, by a comparative study in every grade of the animal kingdom, he proved that the same mode of struggle and defence persists in the mesodermic cells, the phagocytes in all animals in general. In all of them, thanks to a special sensitiveness, Chimiotaxis, phagocytes move towards the intruder, to englobe it and digest it if they can. This reaction for defence by the organism takes place in beings endowed with a vascular system by the migration of the blood-phagocytes which traverse the walls of the blood-vessels in order to betake themselves to the invaded point.
- 80. In higher animals, all the symptoms which accompany this phenomenon of defence and which constitute the classical picture of inflammation (a heightened temperature, pain, redness, tumefaction) are due to the complexity of the organism; but the essence, the primum movens of inflammation, with them also, is a digestive action of the phagocytes upon the noxious agent, therefore a salutary reaction of the organism, essentially similar to the normal digestion of inferior beings. Metchnikoff adduced numerous examples giving evidence of the genetic link which exists between inflammation and normal intracellular digestion, and while establishing the evolution of the former on biological and experimental bases, he showed at the same time the close connection which binds normal biology and pathological biology. This series of lectures formed a volume which appeared in 1892 under the title of Leçons sur la pathologie comparée de l’inflammation, a book which contributed to the acceptation of the phagocyte theory and which showed the importance of Natural History applied to Medicine.
- 81. CHAPTER XXIV Cholera — Experiments on himself and others — Illness of M. Jupille — Death of an epileptic subject — Insufficient results. The acute period of the struggle in defence of the phagocyte theory now seemed to have come to an end and Metchnikoff turned his thoughts towards a new field of ideas. Having elucidated the essence of inflammation, he wished to study the origin of another pathological symptom, i.e. the rise in temperature which constitutes a feverish condition. To that end he undertook a succession of experiments on cold-blooded animals; he injected microbes into crocodiles and serpents, hoping thus to provoke a rise in their temperature. But those experiments did not give the results expected. In the meanwhile (1892) cholera had made its appearance in France; the specificity of the cholera vibrio was not finally established at that time. The observations made by Pettenkoffer on the immunity of certain regions, despite the presence of the cholera vibrio in the water, and the experiments made upon himself by that scientist, seemed to plead against the specificity of the cholera vibrio; but other facts spoke in its favour. Desirous of solving this question, Metchnikoff went to a cholera centre in Brittany in order to fetch the necessary materials. Having done so, he attempted to produce cholera in divers kinds of animals, but without success.
- 82. As he failed to solve the problem of the specificity of the cholera vibrio on animals, he resolved to experiment upon himself and consumed a culture of cholera vibriones. He did not contract cholera, which made him doubt the specificity of the vibrio, and therefore he consented to repeat the experiment on one of his workers (M. Latapie) who offered to submit to it: the result was the same. He then did not hesitate to accept the offer of a second volunteer (M. Jupille). The preceding results having led him to suppose that the cholera vibrio became attenuated in vitro and might perhaps serve as a vaccine against cholera, he gave a culture of long standing to the young volunteer. To his astonishment and despair, Jupille began to manifest the typical symptoms of cholera, and a doctor who was particularly conversant with the clinical chart of the disease declared the case a severe one because of the nervous symptoms which accompanied it. Metchnikoff was in mortal anxiety, and even said to himself that he could not survive a fatal issue. Fortunately the patient recovered, and this terrifying experiment proved indisputably the specificity of the cholera vibrio. Yet the irregularity of its action showed that in certain cases conditions existed which prevented the inception of the disease, and Metchnikoff supposed that this might be due to the action of the different intestinal micro-organisms. In order to simplify the question, he began by making experiments outside the organism. He sowed the cholera vibrio with divers other microbes and saw that some of them facilitated its culture whilst others prevented it. Similar experiments within the organism of animals gave no conclusive results; the simultaneous ingestion of the cholera vibrio and of favourable microbes did not induce cholera. The flora of the intestines, complex as it is, probably played a part on which it was difficult to throw any light. Yet Metchnikoff did not give up the idea of producing a vaccine against this disease with attenuated microbes, or, if not, to prevent its inception by preventive microbes. His thesis was strengthened when one of his pupils, Dr. Sanarelli, discovered a series of choleriform bacilli in the absence of
- 83. any cholera epidemic, one of those microbes being found at Versailles, a town which had remained immune during every cholera epidemic. Metchnikoff thought that this microbe, or some choleriform bacillus, similar though not specific, probably served as a natural vaccine against cholera in those localities which were spared by the epidemic though the cholera vibrio was brought there. This was a question that could only be solved by experiment. At the time when he had himself absorbed a cholera culture, Metchnikoff admitted the risk of catching the disease; still, his eagerness to solve the problem had silenced in him all other considerations and feelings opposed to his irresistible desire to attempt the experiment. This “psychosis,” as he himself called it later, recurred now, in spite of all the emotions he had gone through on the previous occasion, and he decided once again to experiment on man. It is true that he now only had to deal with choleriform microbes from Versailles which he believed to be quite harmless as they came from the water of a locality free from cholera. He therefore ingested some of the Versailles choleriform vibriones and gave some to several other people. Contrary to expectation, one of the latter, an incurable epileptic, showed some symptoms of cholera, but recovered. But as, a short time later, this patient died from a cause which remained obscure, Metchnikoff thought that possibly the experiment might have had something to do with it, and finally resolved to perform no other experiments on human beings. How could that unforeseen result be explained? Metchnikoff supposed that the intestine of the subject contained favourable microbes which had exalted the virulence of the bacillus, in itself weak and innocuous. If it were so, then certain intestinal microbes would influence the inception of diseases and the action of the micro-organisms would vary according to the society in which they found themselves. As such problems could only be solved through experiment, he again energetically sought for a means of conferring cholera upon animals. After many failures and difficulties, it occurred
- 84. to him to try new-born animals whose intestinal flora, not yet developed, could not interfere with the swarming of the ingested bacilli. He chose young suckling rabbits for his experiments and, with the aid of favourable microbes, he succeeded at last in giving them characteristic cholera, through ingestion; thus it became possible to study intestinal cholera on these animals. However, numerous researches on the prevention of cholera by means of divers microbes gave no results sufficiently conclusive to permit their application to human beings. The problem was rendered extremely complicated and difficult by the many and varied influences of numerous intestinal microbes and the inconstancy of microbian species in the same individual.
- 85. CHAPTER XXV Pfeiffer’s experiments, 1895 — The Buda-Pest Congress — Extracellular destruction of microbes — Reaction of the organism against toxins — Dr. Besredka’s researches — Macrophages — The Moscow Congress, 1897 — Bordet’s experiments. Metchnikoff had scarcely recovered from all the emotions caused by his experiments on cholera, which he was still studying, when, in 1894, a work appeared by a well-known German scientist, Pfeiffer, bringing out new facts in favour of the extracellular destruction of microbes. Whilst studying the influence of the blood serum within the organism and not outside it as his predecessors had done, he had found that cholera vibriones, injected into the peritoneum of a guinea-pig vaccinated against cholera, were nearly all killed in a few minutes and that they then presented the form of motionless granules in the peritoneal liquid. This granular degenescence, said Pfeiffer, took place apart from the phagocytes and therefore without their intervention. Metchnikoff repeated the experiment at once and ascertained that it was perfectly accurate. The complexity of biological phenomena being very great, he fully admitted the possibility of other means of defence in the organism besides that of the phagocytic reaction. However, this new fact disagreed so much with his own observation, and seemed so isolated, that Metchnikoff supposed an error of interpretation must
- 86. have been made and tried to throw light upon it. He spent sleepless nights seeking the conclusive experiment which might explain Pfeiffer’s phenomenon. His excitement was all the greater that he was very soon going to the International Congress at Buda-Pest, where he intended to expose the results of his new researches, and he feared that he should not have time to make all the experiments which he required in support of his arguments. However, the general impression of the Congress was clearly favourable to the phagocyte theory. This is how M. Roux picturesquely described the scene at Metchnikoff’s Jubilee in 1915: I can see you now at the Buda-Pest Congress in 1894, disputing with your antagonists; with your fiery face, sparkling eyes, and dishevelled hair, you looked like the Dæmon of Science, but your words, your irresistible arguments raised the applause of your audience. “The new facts, which had at first sight seemed to contradict the phagocyte theory, now entered into harmony with it. It was found to be sufficiently comprehensive to reconcile the holders of the humoral theory with the partisans of the cellular theory.” This is how Metchnikoff had reconciled the apparent disagreement of Pfeiffer’s phenomenon with the phagocyte doctrine: he demonstrated, by a series of experiments, that the extracellular destruction of the cholera vibriones in the peritoneum of a guinea- pig vaccinated against cholera, did in no wise depend on the chemical properties of the blood serum, but was simply due to the digestive juices which had escaped from the inside of the leucocytes, damaged by the intraperitoneal injection. Those digestive juices, or cytases, poured into the peritoneal liquid were what killed the injected cholera vibriones and transformed them into “Pfeiffer’s granulations.” On the other hand, if by means of various precautions the phagocytes were left unmolested, the extracellular destruction did not take place and the vibriones were digested within the phagocytes. Metchnikoff used other experiments to prove that the bactericidal property of blood juices did not exist without intervention from the
- 87. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com