Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

Operating Systems and Middleware Supporting

Controlled Interaction Max Hailperin

https://ebookmeta.com/product/operating-systems-and-
middleware-supporting-controlled-interaction-max-hailperin/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Survey of Operating Systems, 7th Edition Jane Holcombe

https://ebookmeta.com/product/survey-of-operating-systems-7th-edition-
jane-holcombe/

ebookmeta.com

Modern Operating Systems 5th Edition Andrew S. Tanenbaum

https://ebookmeta.com/product/modern-operating-systems-5th-edition-
andrew-s-tanenbaum/

ebookmeta.com

Understanding Operating Systems, 8th ed. 8th Edition Ann

Mchoes

https://ebookmeta.com/product/understanding-operating-systems-8th-
ed-8th-edition-ann-mchoes/

ebookmeta.com

MECHANICAL DESIGN AND MANUFACTURING OF ELECTRIC MOTORS

2nd Edition Wei Tong

https://ebookmeta.com/product/mechanical-design-and-manufacturing-of-
electric-motors-2nd-edition-wei-tong/

ebookmeta.com
Contracting and Contract Law in the Age of Artificial
Intelligence 1st Edition Martin Ebers

https://ebookmeta.com/product/contracting-and-contract-law-in-the-age-
of-artificial-intelligence-1st-edition-martin-ebers/

ebookmeta.com

Reference Frame Theory : Development and Applications 1st

Edition Paul C. Krause

https://ebookmeta.com/product/reference-frame-theory-development-and-
applications-1st-edition-paul-c-krause/

ebookmeta.com

Handbook of Single-Cell Technologies Tuhin Subhra Santra

(Editor)

https://ebookmeta.com/product/handbook-of-single-cell-technologies-
tuhin-subhra-santra-editor/

ebookmeta.com

Physique Secrets The Underground Playbook For Building A

Muscular And Aesthetic Male Body Nick Schlager

https://ebookmeta.com/product/physique-secrets-the-underground-
playbook-for-building-a-muscular-and-aesthetic-male-body-nick-
schlager/
ebookmeta.com

What Would You Do If You Weren t Afraid Discover a Life

Filled with Purpose and Joy Through the Secrets of Jewish
Wisdom 1st Edition Michal Oshman
https://ebookmeta.com/product/what-would-you-do-if-you-weren-t-afraid-
discover-a-life-filled-with-purpose-and-joy-through-the-secrets-of-
jewish-wisdom-1st-edition-michal-oshman/
ebookmeta.com
Return of Pal ul don 1st Edition Will Murray

https://ebookmeta.com/product/return-of-pal-ul-don-1st-edition-will-
murray/

ebookmeta.com
Operating Systems and Middleware:
Supporting Controlled Interaction

Max Hailperin
Gustavus Adolphus College

Revised Edition 1.3.1

June 4, 2019
Copyright c 2011–2019 by Max Hailperin.

This work is licensed under the Creative Commons Attribution-ShareAlike

3.0 Unported License. To view a copy of this license, visit

http:// creativecommons.org/ licenses/ by-sa/ 3.0/

or send a letter to Creative Commons, 171 Second Street, Suite 300, San
Francisco, California, 94105, USA.

About the Cover

The cover photo shows the treasury coming into view at the end of the siq, or
defile, leading to the ancient Nabatean city of Petra in present-day Jordan.
The siq is a narrow, winding passage cut deep into the sandstone primarily
by natural geological forces, though it was improved by the Nabateans.
Petra was a thriving spice trading city. Its prosperity can be linked to
several factors, including its location on important trade routes, its access to
water through sophisticated hydraulic engineering, and its easily defensible
character. The siq played an important role in the latter two aspects. Water
conduits were built into the walls of the siq. Meanwhile, the floor of the siq
was just wide enough for a single-file merchant caravan of camels, while
remaining too narrow to serve as a route for attack.
Operating systems and middleware provide a conducive environment for
application programs to interact in a controlled manner, much as Petra must
have served for spice merchants 2000 years ago. Access to communication
and resources remain as important as then, but so does the provision of
tightly controlled interfaces that ensure security.
The photo is by Rhys Davenport, who released it under a Creative Com-
mons Attribution 2.0 Generic license. The photo is available on the web at
http:// www.flickr.com/ photos/ 33122834@N06/ 3437495101/ .
To my family
iv
Contents

Preface xi

1 Introduction 1
1.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 What Is an Operating System? . . . . . . . . . . . . . . . . . 2
1.3 What Is Middleware? . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Objectives for the Book . . . . . . . . . . . . . . . . . . . . . 8
1.5 Multiple Computations on One Computer . . . . . . . . . . . 9
1.6 Interactions Between Computations . . . . . . . . . . . . . . 11
1.7 Supporting Interaction Across Time . . . . . . . . . . . . . . 13
1.8 Supporting Interaction Across Space . . . . . . . . . . . . . . 15
1.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Threads 21
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Example of Multithreaded Programs . . . . . . . . . . . . . . 23
2.3 Reasons for Using Concurrent Threads . . . . . . . . . . . . . 27
2.4 Switching Between Threads . . . . . . . . . . . . . . . . . . . 30
2.5 Preemptive Multitasking . . . . . . . . . . . . . . . . . . . . . 37
2.6 Security and Threads . . . . . . . . . . . . . . . . . . . . . . . 39

3 Scheduling 45
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Thread States . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Scheduling Goals . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.2 Response Time . . . . . . . . . . . . . . . . . . . . . . 54
3.3.3 Urgency, Importance, and Resource Allocation . . . . 55
3.4 Fixed-Priority Scheduling . . . . . . . . . . . . . . . . . . . . 61

v
vi CONTENTS

3.5 Dynamic-Priority Scheduling . . . . . . . . . . . . . . . . . . 65

3.5.1 Earliest Deadline First Scheduling . . . . . . . . . . . 65
3.5.2 Decay Usage Scheduling . . . . . . . . . . . . . . . . . 66
3.6 Proportional-Share Scheduling . . . . . . . . . . . . . . . . . 71
3.7 Security and Scheduling . . . . . . . . . . . . . . . . . . . . . 79

4 Synchronization and Deadlocks 93

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2 Races and the Need for Mutual Exclusion . . . . . . . . . . . 95
4.3 Mutexes and Monitors . . . . . . . . . . . . . . . . . . . . . . 98
4.3.1 The Mutex Application Programming Interface . . . . 99
4.3.2 Monitors: A More Structured Interface to Mutexes . . 103
4.3.3 Underlying Mechanisms for Mutexes . . . . . . . . . . 106
4.4 Other Synchronization Patterns . . . . . . . . . . . . . . . . . 110
4.4.1 Bounded Buffers . . . . . . . . . . . . . . . . . . . . . 113
4.4.2 Readers/Writers Locks . . . . . . . . . . . . . . . . . . 115
4.4.3 Barriers . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.5 Condition Variables . . . . . . . . . . . . . . . . . . . . . . . 117
4.6 Semaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.7 Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.7.1 The Deadlock Problem . . . . . . . . . . . . . . . . . . 126
4.7.2 Deadlock Prevention Through Resource Ordering . . . 128
4.7.3 Ex Post Facto Deadlock Detection . . . . . . . . . . . 130
4.7.4 Immediate Deadlock Detection . . . . . . . . . . . . . 132
4.8 Synchronization/Scheduling Interactions . . . . . . . . . . . . 135
4.8.1 Priority Inversion . . . . . . . . . . . . . . . . . . . . . 135
4.8.2 The Convoy Phenomenon . . . . . . . . . . . . . . . . 137
4.9 Nonblocking Synchronization . . . . . . . . . . . . . . . . . . 141
4.10 Security and Synchronization . . . . . . . . . . . . . . . . . . 145

5 Atomic Transactions 161

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.2 Example Applications of Transactions . . . . . . . . . . . . . 164
5.2.1 Database Systems . . . . . . . . . . . . . . . . . . . . 165
5.2.2 Message-Queuing Systems . . . . . . . . . . . . . . . . 169
5.2.3 Journaled File Systems . . . . . . . . . . . . . . . . . 174
5.3 Mechanisms to Ensure Atomicity . . . . . . . . . . . . . . . . 176
5.3.1 Serializability: Two-Phase Locking . . . . . . . . . . . 176
5.3.2 Failure Atomicity: Undo Logging . . . . . . . . . . . . 185
5.4 Transaction Durability: Write-Ahead Logging . . . . . . . . . 188
CONTENTS vii

5.5 Additional Transaction Mechanisms . . . . . . . . . . . . . . 192

5.5.1 Increased Transaction Concurrency: Reduced Isolation 193
5.5.2 Coordinated Transaction Participants: Two-Phase Com-
mit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.6 Security and Transactions . . . . . . . . . . . . . . . . . . . . 198

6 Virtual Memory 209

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.2 Uses for Virtual Memory . . . . . . . . . . . . . . . . . . . . . 214
6.2.1 Private Storage . . . . . . . . . . . . . . . . . . . . . . 214
6.2.2 Controlled Sharing . . . . . . . . . . . . . . . . . . . . 215
6.2.3 Flexible Memory Allocation . . . . . . . . . . . . . . . 218
6.2.4 Sparse Address Spaces . . . . . . . . . . . . . . . . . . 220
6.2.5 Persistence . . . . . . . . . . . . . . . . . . . . . . . . 222
6.2.6 Demand-Driven Program Loading . . . . . . . . . . . 223
6.2.7 Efficient Zero Filling . . . . . . . . . . . . . . . . . . . 224
6.2.8 Substituting Disk Storage for RAM . . . . . . . . . . 225
6.3 Mechanisms for Virtual Memory . . . . . . . . . . . . . . . . 226
6.3.1 Software/Hardware Interface . . . . . . . . . . . . . . 228
6.3.2 Linear Page Tables . . . . . . . . . . . . . . . . . . . . 232
6.3.3 Multilevel Page Tables . . . . . . . . . . . . . . . . . . 237
6.3.4 Hashed Page Tables . . . . . . . . . . . . . . . . . . . 242
6.3.5 Segmentation . . . . . . . . . . . . . . . . . . . . . . . 245
6.4 Policies for Virtual Memory . . . . . . . . . . . . . . . . . . . 250
6.4.1 Fetch Policy . . . . . . . . . . . . . . . . . . . . . . . . 251
6.4.2 Placement Policy . . . . . . . . . . . . . . . . . . . . . 253
6.4.3 Replacement Policy . . . . . . . . . . . . . . . . . . . 254
6.5 Security and Virtual Memory . . . . . . . . . . . . . . . . . . 262

7 Processes and Protection 273

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.2 POSIX Process Management API . . . . . . . . . . . . . . . . 275
7.3 Protecting Memory . . . . . . . . . . . . . . . . . . . . . . . . 285
7.3.1 The Foundation of Protection: Two Processor Modes 286
7.3.2 The Mainstream: Multiple Address Space Systems . . 289
7.3.3 An Alternative: Single Address Space Systems . . . . 291
7.4 Representing Access Rights . . . . . . . . . . . . . . . . . . . 293
7.4.1 Fundamentals of Access Rights . . . . . . . . . . . . . 293
7.4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 299
7.4.3 Access Control Lists and Credentials . . . . . . . . . . 303
viii CONTENTS

7.5 Alternative Granularities of Protection . . . . . . . . . . . . . 311

7.5.1 Protection Within a Process . . . . . . . . . . . . . . . 312
7.5.2 Protection of Entire Simulated Machines . . . . . . . . 313
7.6 Security and Protection . . . . . . . . . . . . . . . . . . . . . 317

8 Files and Other Persistent Storage 333

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
8.2 Disk Storage Technology . . . . . . . . . . . . . . . . . . . . . 336
8.3 POSIX File API . . . . . . . . . . . . . . . . . . . . . . . . . 340
8.3.1 File Descriptors . . . . . . . . . . . . . . . . . . . . . . 340
8.3.2 Mapping Files into Virtual Memory . . . . . . . . . . 345
8.3.3 Reading and Writing Files at Specified Positions . . . 348
8.3.4 Sequential Reading and Writing . . . . . . . . . . . . 348
8.4 Disk Space Allocation . . . . . . . . . . . . . . . . . . . . . . 350
8.4.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 351
8.4.2 Locality . . . . . . . . . . . . . . . . . . . . . . . . . . 354
8.4.3 Allocation Policies and Mechanisms . . . . . . . . . . 356
8.5 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
8.5.1 Data Location Metadata . . . . . . . . . . . . . . . . . 359
8.5.2 Access Control Metadata . . . . . . . . . . . . . . . . 368
8.5.3 Other Metadata . . . . . . . . . . . . . . . . . . . . . 371
8.6 Directories and Indexing . . . . . . . . . . . . . . . . . . . . . 371
8.6.1 File Directories Versus Database Indexes . . . . . . . . 371
8.6.2 Using Indexes to Locate Files . . . . . . . . . . . . . . 373
8.6.3 File Linking . . . . . . . . . . . . . . . . . . . . . . . . 374
8.6.4 Directory and Index Data Structures . . . . . . . . . . 378
8.7 Metadata Integrity . . . . . . . . . . . . . . . . . . . . . . . . 379
8.8 Polymorphism in File System Implementations . . . . . . . . 383
8.9 Security and Persistent Storage . . . . . . . . . . . . . . . . . 384

9 Networking 395
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
9.1.1 Networks and Internets . . . . . . . . . . . . . . . . . 396
9.1.2 Protocol Layers . . . . . . . . . . . . . . . . . . . . . . 398
9.1.3 The End-to-End Principle . . . . . . . . . . . . . . . . 401
9.1.4 The Networking Roles of Operating Systems, Middle-
ware, and Application Software . . . . . . . . . . . . . 402
9.2 The Application Layer . . . . . . . . . . . . . . . . . . . . . . 403
9.2.1 The Web as a Typical Example . . . . . . . . . . . . . 403
CONTENTS ix

9.2.2 The Domain Name System: Application Layer as In-

frastructure . . . . . . . . . . . . . . . . . . . . . . . . 406
9.2.3 Distributed File Systems: An Application Viewed Through
Operating Systems . . . . . . . . . . . . . . . . . . . . 409
9.3 The Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 411
9.3.1 Socket APIs . . . . . . . . . . . . . . . . . . . . . . . . 412
9.3.2 TCP, the Dominant Transport Protocol . . . . . . . . 418
9.3.3 Evolution Within and Beyond TCP . . . . . . . . . . 421
9.4 The Network Layer . . . . . . . . . . . . . . . . . . . . . . . . 422
9.4.1 IP, Versions 4 and 6 . . . . . . . . . . . . . . . . . . . 422
9.4.2 Routing and Label Switching . . . . . . . . . . . . . . 425
9.4.3 Network Address Translation: An End to End-to-End? 426
9.5 The Link and Physical Layers . . . . . . . . . . . . . . . . . . 429
9.6 Network Security . . . . . . . . . . . . . . . . . . . . . . . . . 431
9.6.1 Security and the Protocol Layers . . . . . . . . . . . . 432
9.6.2 Firewalls and Intrusion Detection Systems . . . . . . . 434
9.6.3 Cryptography . . . . . . . . . . . . . . . . . . . . . . . 435

10 Messaging, RPC, and Web Services 447

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
10.2 Messaging Systems . . . . . . . . . . . . . . . . . . . . . . . . 448
10.3 Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . 451
10.3.1 Principles of Operation for RPC . . . . . . . . . . . . 452
10.3.2 An Example Using Java RMI . . . . . . . . . . . . . . 455
10.4 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
10.5 Security and Communication Middleware . . . . . . . . . . . 461

11 Security 467
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
11.2 Security Objectives and Principles . . . . . . . . . . . . . . . 468
11.3 User Authentication . . . . . . . . . . . . . . . . . . . . . . . 474
11.3.1 Password Capture Using Spoofing and Phishing . . . . 475
11.3.2 Checking Passwords Without Storing Them . . . . . . 477
11.3.3 Passwords for Multiple, Independent Systems . . . . . 477
11.3.4 Two-Factor Authentication . . . . . . . . . . . . . . . 477
11.4 Access and Information-Flow Controls . . . . . . . . . . . . . 480
11.5 Viruses and Worms . . . . . . . . . . . . . . . . . . . . . . . . 485
11.6 Security Assurance . . . . . . . . . . . . . . . . . . . . . . . . 489
11.7 Security Monitoring . . . . . . . . . . . . . . . . . . . . . . . 491
11.8 Key Security Best Practices . . . . . . . . . . . . . . . . . . . 494
x CONTENTS

A Stacks 505
A.1 Stack-Allocated Storage: The Concept . . . . . . . . . . . . . 506
A.2 Representing a Stack in Memory . . . . . . . . . . . . . . . . 507
A.3 Using a Stack for Procedure Activations . . . . . . . . . . . . 508

Bibliography 511

Index 527
Preface

Suppose you sit down at your computer to check your email. One of the
messages includes an attached document, which you are to edit. You click
the attachment, and it opens up in another window. After you start edit-
ing the document, you realize you need to leave for a trip. You save the
document in its partially edited state and shut down the computer to save
energy while you are gone. Upon returning, you boot the computer back
up, open the document, and continue editing.
This scenario illustrates that computations interact. In fact, it demon-
strates at least three kinds of interactions between computations. In each
case, one computation provides data to another. First, your email program
retrieves new mail from the server, using the Internet to bridge space. Sec-
ond, your email program provides the attachment to the word processor,
using the operating system’s services to couple the two application pro-
grams. Third, the invocation of the word processor that is running before
your trip provides the partially edited document to the invocation running
after your return, using disk storage to bridge time.
In this book, you will learn about all three kinds of interaction. In all
three cases, interesting software techniques are needed in order to bring the
computations into contact, yet keep them sufficiently at arm’s length that
they don’t compromise each other’s reliability. The exciting challenge, then,
is supporting controlled interaction. This includes support for computations
that share a single computer and interact with one another, as your email
and word processing programs do. It also includes support for data storage
and network communication. This book describes how all these kinds of
support are provided both by operating systems and by additional software
layered on top of operating systems, which is known as middleware.

xi
xii PREFACE

Audience
If you are an upper-level computer science student who wants to under-
stand how contemporary operating systems and middleware products work
and why they work that way, this book is for you. In this book, you will
find many forms of balance. The high-level application programmer’s view,
focused on the services that system software provides, is balanced with a
lower-level perspective, focused on the mechanisms used to provide those
services. Timeless concepts are balanced with concrete examples of how
those concepts are embodied in a range of currently popular systems. Pro-
gramming is balanced with other intellectual activities, such as the scientific
measurement of system performance and the strategic consideration of sys-
tem security in its human and business context. Even the programming
languages used for examples are balanced, with some examples in Java and
others in C or C++. (Only limited portions of these languages are used,
however, so that the examples can serve as learning opportunities, not stum-
bling blocks.)

Systems Used as Examples

Most of the examples throughout the book are drawn from the two dominant
families of operating systems: Microsoft Windows and the UNIX family,
including especially Linux and Mac OS X. Using this range of systems pro-
motes the students’ flexibility. It also allows a more comprehensive array of
concepts to be concretely illustrated, as the systems embody fundamentally
different approaches to some problems, such as the scheduling of processors’
time and the tracking of files’ disk space.
Most of the examples are drawn from the stable core portions of the
operating systems and, as such, are equally applicable to a range of spe-
cific versions. Whenever Microsoft Windows is mentioned without further
specification, the material should apply to Windows NT, Windows 2000,
Windows XP, Windows Server 2003, Windows Vista, Windows 2008, Win-
dows 7, Windows 8, Windows 2012, and Windows 10. All Linux examples
are from version 2.6, though much of the material applies to other versions
as well. Wherever actual Linux source code is shown (or whenever fine de-
tails matter for other reasons), the specific subversion of 2.6 is mentioned
in the end-of-chapter notes. Most of the Mac OS X examples originated
with version 10.4, also known as Tiger, but should be applicable to other
versions.
PREFACE xiii

Where the book discusses the protection of each process’s memory, one
additional operating system is brought into the mix of examples, in order
to illustrate a more comprehensive range of alternative designs. The IBM
iSeries, formerly known as the AS/400, embodies an interesting approach
to protection that might see wider application within current students’ life-
times. Rather than giving each process its own address space (as Linux,
Windows, and Mac OS X do), the iSeries allows all processes to share a
single address space and to hold varying access permissions to individual
objects within that space.
Several middleware systems are used for examples as well. The Ora-
cle database system is used to illustrate deadlock detection and recovery
as well as the use of atomic transactions. Messaging systems appear both
as another application of atomic transactions and as an important form of
communication middleware, supporting distributed applications. The spe-
cific messaging examples are drawn from the IBM WebSphere MQ system
(formerly MQSeries) and the Java Message Service (JMS) interface, which
is part of Java 2 Enterprise Edition (J2EE). The other communication mid-
dleware example is Java RMI (Remote Method Invocation).

Organization of the Text

Chapter 1 provides an overview of the text as a whole, explaining what an
operating system is, what middleware is, and what sorts of support these
systems provide for controlled interaction.
The next nine chapters work through the varieties of controlled interac-
tion that are exemplified by the scenario at the beginning of the preface: in-
teraction between concurrent computations on the same system (as between
your email program and your word processor), interaction across time (as
between your word processor before your trip and your word processor after
your trip), and interaction across space (as between your email program and
your service provider’s email server).
The first of these three topics is controlled interaction between computa-
tions operating at one time on a particular computer. Before such interaction
can make sense, you need to understand how it is that a single computer
can be running more than one program, such as an email program in one
window and a word processing program in another. Therefore, Chapter 2
explains the fundamental mechanism for dividing a computer’s attention
between concurrent computations, known as threads. Chapter 3 continues
with the related topic of scheduling. That is, if the computer is dividing its
xiv PREFACE

time between computations, it needs to decide which ones to work on at any

moment.
With concurrent computations explained, Chapter 4 introduces con-
trolled interactions between them by explaining synchronization, which is
control over the threads’ relative timing. For example, this chapter explains
how, when your email program sends a document to your word processor,
the word processor can be constrained to read the document only after the
email program writes it. One particularly important form of synchroniza-
tion, atomic transactions, is the topic of Chapter 5. Atomic transactions
are groups of operations that take place as an indivisible unit; they are
most commonly supported by middleware, though they are also playing an
increasing role in operating systems.
Other than synchronization, the main way that operating systems con-
trol the interaction between computations is by controlling their access to
memory. Chapter 6 explains how this is achieved using the technique known
as virtual memory. That chapter also explains the many other objectives
this same technique can serve. Virtual memory serves as the foundation for
Chapter 7’s topic, which is processes. A process is the fundamental unit of
computation for protected access, just as a thread is the fundamental unit
of computation for concurrency. A process is a group of threads that share a
protection environment; in particular, they share the same access to virtual
memory.
The next three chapters move outside the limitations of a single com-
puter operating in a single session. First, consider the document stored
before a trip and available again after it. Chapter 8 explains persistent
storage mechanisms, focusing particularly on the file storage that operat-
ing systems provide. Second, consider the interaction between your email
program and your service provider’s email server. Chapter 9 provides an
overview of networking, including the services that operating systems make
available to programs such as the email client and server. Chapter 10 ex-
tends this discussion into the more sophisticated forms of support provided
by communication middleware, such as messaging systems, RMI, and web
services.
Finally, Chapter 11 focuses on security. Because security is a pervasive
issue, the preceding ten chapters all provide some information on it as well.
Specifically, the final section of each chapter points out ways in which se-
curity relates to that chapter’s particular topic. However, even with that
coverage distributed throughout the book, a chapter specifically on security
is needed, primarily to elevate it out of technical particulars and talk about
general principles and the human and organizational context surrounding
PREFACE xv

the computer technology.

The best way to use these chapters is in consecutive order. However,
Chapter 5 can be omitted with only minor harm to Chapters 8 and 10, and
Chapter 9 can be omitted if students are already sufficiently familiar with
networking.

Relationship to Computer Science Curriculum 2008

Operating systems are traditionally the subject of a course required for all
computer science majors. In recent years, however, there has been increasing
interest in the idea that upper-level courses should be centered less around
particular artifacts, such as operating systems, and more around cross-
cutting concepts. In particular, the Computing Curricula 2001 (CC2001)
and its interim revision, Computer Science Curriculum 2008 (CS2008), pro-
vide encouragement for this approach, at least as one option. Most colleges
and universities still retain a relatively traditional operating systems course,
however. Therefore, this book steers a middle course, moving in the direc-
tion of the cross-cutting concerns while retaining enough familiarity to be
broadly adoptable.
The following table indicates the placement within this text of knowledge
units from CS2008’s computer science body of knowledge. Those knowledge
units designated as core units within CS2008 are listed in italics. The book
covers all core operating systems (OS) units, as well as one elective OS unit.
The overall amount of coverage for each unit is always at least that rec-
ommended by CS2008, though sometimes the specific subtopics don’t quite
correspond exactly. Outside the OS area, this book’s most substantial cov-
erage is of Net-Centric Computing (NC); another major topic, transaction
processing, comes from Information Management (IM). In each row, the
listed chapters contain the bulk of the knowledge unit’s coverage, though
xvi PREFACE

some topics may be elsewhere.

Knowledge unit
(italic indicates core units in CS2008) Chapter(s)
OS/OverviewOfOperatingSystems 1
OS/OperatingSystemPrinciples 1, 7
OS/Concurrency 2, 4
OS/SchedulingAndDispatch 3
OS/MemoryManagement 6
OS/SecurityAndProtection 7, 11
OS/FileSystems 8
NC/Introduction 9
NC/NetworkCommunication (partial coverage) 9
NC/NetworkSecurity (partial coverage) 9
NC/WebOrganization (partial coverage) 9
NC/NetworkedApplications (partial coverage) 10
IM/TransactionProcessing 5

Your Feedback Is Welcome

Comments, suggestions, and bug reports are welcome; please send email to
[email protected] or use the github issue tracker. Bug reports can earn
you a bounty of $2.56 apiece as a token of gratitude. (The great computer
scientist Donald Knuth started this tradition. Given how close to bug-free
his publications have become, it seems to work.) For purposes of this reward,
the definition of a bug is simple: if as a result of your comment the author
chooses to make a change, then you have pointed out a bug. The change
need not be the one you suggested, and the bug need not be technical in
nature. Unclear writing qualifies, for example.

Features of the Text

Each chapter concludes with five standard elements. The last numbered sec-
tion within the chapter is always devoted to security matters related to the
chapter’s topic. Next comes three different lists of opportunities for active
participation by the student: exercises, programming projects, and explo-
ration projects. Finally, the chapter ends with historical and bibliographic
notes.
The distinction between exercises, programming projects, and explo-
ration projects needs explanation. An exercise can be completed with no
PREFACE xvii

outside resources beyond paper and pencil: you need just this textbook and
your mind. That does not mean all the exercises are cut and dried, however.
Some may call upon you to think creatively; for these, no one answer is cor-
rect. Programming projects require a nontrivial amount of programming;
that is, they require more than making a small, easily identified change in
an existing program. However, a programming project may involve other
activities beyond programming. Several of them involve scientific measure-
ment of performance effects, for example; these exploratory aspects may
even dominate over the programming aspects. An exploration project, on
the other hand, can be an experiment that can be performed with no real
programming; at most you might change a designated line within an ex-
isting program. The category of exploration projects does not just include
experimental work, however. It also includes projects that require you to do
research on the Internet or using other library resources.

Supplemental Resources
The author of this text is making supplemental resources available on his own
website. Additionally, the publisher of the earlier first edition commissioned
additional resources from independent supplement authors, which may still
be available through the publisher’s website and would largely still apply
to this revised edition. The author’s website, https:// gustavus.edu/ +max/
os-book/ , contains at least the following materials:
• Full text of this revised edition

• Source code in Java, C, or C++ for all programs that are shown in
the text

• Artwork files for all figures in the text

• A link to the book’s github site, which includes an issue tracker (errata
list)

About the Revised Edition

Course Technology published the first edition of this book in January of 2006
and in October of 2010 assigned the copyright back to the author, giving
him the opportunity to make it freely available. This revised edition closely
follows the first edition; rather than being a thorough update, it is aimed at
three narrow goals:
xviii PREFACE

• All errata reported in the first edition are corrected.

• A variety of other minor improvements appear throughout, such as

clarified explanations and additional exercises, projects, and end-of-
chapter notes.

• Two focused areas received more substantial updates:

– The explanation of Linux’s scheduler was completely replaced

to correspond to the newer “Completely Fair Scheduler” (CFS),
including its group scheduling feature.
– A new section, 4.9, was added on nonblocking synchronization.

In focusing on these limited goals, a key objective was to maintain as

much compatibility with the first edition as possible. Although page num-
bering changed, most other numbers stayed the same. All new exercises
and projects were added to the end of the corresponding lists for that rea-
son. The only newly added section, 4.9, is near the end of its chapter; thus,
the only changed section number is that the old Section 4.9 (“Security and
Synchronization”) became 4.10. Only in Chapter 4 did any figure numbers
change.
It is my hope that others will join me in making further updates and
improvements to the text. I am releasing it under a Creative Commons
license that allows not just free copying, but also the freedom to make mod-
ifications, so long as the modified version is released under the same terms.
In order to make such modifications practical, I’m not just releasing the
book in PDF form, but also as a collection of LATEX source files that can
be edited and then run through the pdflatex program (along with bibtex
and makeindex). The source file collection also includes PDF files of all
artwork figures; Course Technology has released the rights to the artwork
they contracted to have redrawn. All of this is on the github site.
If you produce a modified version of this text, the Creative Commons
license allows you considerable flexibility in how you make your modified
version available. I would urge you to contribute it back using a “pull
request” on the main github site—we will all benefit from having a central
repository of progress. Separate materials to supplement the text would also
be welcome. One category that occurs to me is animations or screencasts;
the static figures in the text are rather limited. Another worthwhile project
would be to transform the text into a more contribution-friendly form, such
as a wiki.
PREFACE xix

Acknowledgments
This book was made possible by financial and logistical support from my
employer, Gustavus Adolphus College, and moral support from my family.
I would like to acknowledge the contributions of the publishing team, espe-
cially developmental editor Jill Batistick and Product Manager Alyssa Pratt.
I am also grateful to my students for doing their own fair share of teaching.
I particularly appreciate the often extensive comments I received from the
following individuals, each of whom reviewed one or more chapters: Dan
Cosley, University of Minnesota, Twin Cities; Allen Downey, Franklin W.
Olin College of Engineering; Michael Goldweber, Xavier University; Ramesh
Karne, Towson University; G. Manimaran, Iowa State University; Alexander
Manov, Illinois Institute of Technology; Peter Reiher, University of Califor-
nia, Los Angeles; Rich Salz, DataPower Technology; Dave Schulz, Wisconsin
Lutheran College; Sanjeev Setia, George Mason University; and Jon Weiss-
man, University of Minnesota, Twin Cities. Although I did not adopt all
their suggestions, I did not ignore any of them, and I appreciate them all.
In preparing the revised edition, I took advantage of suggestions from
many readers. I would like to thank all of them, even those I’ve managed
to lose track of, to whom I also apologize. Those I can thank by name are
Joel Adams, Michael Brackney, Jack Briner, Justin Delegard, Ben Follis,
MinChan Kim, Finn Kuusisto, Matt Lindner, Milo Martin, Gabe Schmidt,
Fritz Sieker, and Alex Wauck.
Since the initial release of the revised edition, user suggestions have
continued to drive most of the progress. The github issue tracker and pull
requests show the history of these valuable contributions.
xx PREFACE
Chapter 1

Introduction

1.1 Chapter Overview

This book covers a lot of ground. In it, I will explain to you the basic
principles that underlie a broad range of systems and also give you concrete
examples of how those principles play out in several specific systems. You
will see not only some of the internal workings of low-level infrastructure,
but also how to build higher-level applications on top of that infrastructure
to make use of its services. Moreover, this book will draw on material you
may have encountered in other branches of computer science and engineer-
ing and engage you in activities ranging from mathematical proofs to the
experimental measurement of real-world performance and the consideration
of how systems are used and abused in social context.
Because the book as a whole covers so much ground, this chapter is
designed to give you a quick view of the whole terrain, so that you know
what you are getting into. This is especially important because several of
the topics I cover are interrelated, so that even though I carefully designed
the order of presentation, I am still going to confront you with occasional
forward references. You will find, however, that this introductory chapter
gives you a sufficient overview of all the topics so that you won’t be mystified
when a chapter on one makes some reference to another.
In Section 1.2, I will explain what an operating system is, and in Sec-
tion 1.3, I will do the same for middleware. After these two sections, you
will know what general topic you are studying. Section 1.4 gives you some
reasons for studying that topic, by explaining several roles that I hope this
book will serve for you.
After the very broad overview provided by these initial sections, the

1
2 CHAPTER 1. INTRODUCTION

remaining sections of this chapter are somewhat more focused. Each corre-
sponds to one or more of the later chapters and explains one important cat-
egory of service provided by operating systems and middleware. Section 1.5
explains how a single computer can run several computations concurrently,
a topic addressed in more depth by Chapters 2 and 3. Section 1.6 explains
how interactions between those concurrent computations can be kept under
control, the topic of Chapters 4 through 7. Sections 1.7 and 1.8 extend
the range of interacting computations across time and space, respectively,
through mechanisms such as file systems and networking. They preview
Chapter 8 and Chapters 9 and 10. Finally, Section 1.9 introduces the topic
of security, a topic I revisit at the end of each chapter and then focus on in
Chapter 11.

1.2 What Is an Operating System?

An operating system is software that uses the hardware resources of a com-
puter system to provide support for the execution of other software. Specif-
ically, an operating system provides the following services:

• The operating system allows multiple computations to take place con-

currently on a single computer system. It divides the hardware’s time
between the computations and handles the shifts of focus between the
computations, keeping track of where each one leaves off so that it can
later correctly resume.

• The operating system controls the interactions between the concurrent

computations. It can enforce rules, such as forbidding computations
from modifying data structures while other computations are accessing
those structures. It can also provide isolated areas of memory for
private use by the different computations.

• The operating system can provide support for controlled interaction of

computations even when they do not run concurrently. In particular,
general-purpose operating systems provide file systems, which allow
computations to read data from files written by earlier computations.
This feature is optional because an embedded system, such as the
computer controlling a washing machine, might in some cases run an
operating system, but not provide a file system or other long-term
storage.
1.2. WHAT IS AN OPERATING SYSTEM? 3

• The operating system can provide support for controlled interaction

of computations spread among different computer systems by using
networking. This is another standard feature of general-purpose oper-
ating systems.

These services are illustrated in Figure 1.1.

If you have programmed only general-purpose computers, such as PCs,
workstations, and servers, you have probably never encountered a computer
system that was not running an operating system or that did not allow mul-
tiple computations to be ongoing. For example, when you boot up your own
computer, chances are it runs Linux, Microsoft Windows, or Mac OS X and
that you can run multiple application programs in individual windows on
the display screen. These three operating systems will serve as my primary
examples throughout the book.
To illustrate that a computer can run a single program without an op-
erating system, consider embedded systems. A typical embedded system
might have neither keyboard nor display screen. Instead, it might have
temperature and pressure sensors and an output that controls the fuel in-
jectors of your car. Alternatively, it might have a primitive keyboard and
display, as on a microwave oven, but still be dedicated to running a single
program.
Some of the most sophisticated embedded systems run multiple cooper-
ating programs and use operating systems. However, more mundane embed-
ded systems take a simpler form. A single program is directly executed by
the embedded processor. That program contains instructions to read from
input sensors, carry out appropriate computations, and write to the output
devices. This sort of embedded system illustrates what is possible without
an operating system. It will also serve as a point of reference as I contrast
my definition of an operating system with an alternative definition.
One popular alternative definition of an operating system is that it pro-
vides application programmers with an abstract view of the underlying hard-
ware resources, taking care of the low-level details so that the applications
can be programmed more simply. For example, the programmer can write
a simple statement to output a string without concern for the details of
making each character appear on the display screen.
I would counter by remarking that abstraction can be provided with-
out an operating system, by linking application programs with separately
written libraries of supporting procedures. For example, a program could
output a string using the standard mechanism of a programming language,
such as C++ or Java. The application programmer would not need to know
4 CHAPTER 1. INTRODUCTION

networking
Application Application Application

Application Operating System Operating System

File

(a) (b)

Figure 1.1: Without an operating system, a computer can directly execute

a single program, as shown in part (a). Part (b) shows that with an oper-
ating system, the computer can support concurrent computations, control
the interactions between them (suggested by the dashed line), and allow
communication across time and space by way of files and networking.

anything about hardware. However, rather than running on an operating

system, the program could be linked together with a library that performed
the output by appropriately manipulating a microwave oven’s display panel.
Once running on the oven’s embedded processor, the library and the appli-
cation code would be a single program, nothing more than a sequence of
instructions to directly execute. However, from the application program-
mer’s standpoint, the low-level details would have been successfully hidden.
To summarize this argument, a library of input/output routines is not
the same as an operating system, because it satisfies only the first part of
my definition. It does use underlying hardware to support the execution of
other software. However, it does not provide support for controlled inter-
action between computations. In fairness to the alternative viewpoint, it is
the more historically grounded one. Originally, a piece of software could be
called an operating system without supporting controlled interaction. How-
ever, the language has evolved such that my definition more closely reflects
current usage.
I should also address one other alternative view of operating systems,
because it is likely to be the view you have formed from your own experience
using general-purpose computers. You are likely to think of an operating
system as the software with which you interact in order to carry out tasks
such as running application programs. Depending on the user interface to
which you are accustomed, you might think the operating system is what
allows you to click program icons to run them, or you might think the
operating system is what interprets commands you type.
1.2. WHAT IS AN OPERATING SYSTEM? 5

There is an element of truth to this perception. The operating system

does provide the service of executing a selected application program. How-
ever, the operating system provides this service not to human users clicking
icons or typing commands, but to other programs already running on the
computer, including the one that handles icon clicks or command entries.
The operating system allows one program that is running to start another
program running. This is just one of the many services the operating system
provides to running programs. Another example service is writing output
into a file. The sum total of features the operating system makes available
for application programmers to use in their programs is called the Applica-
tion Programming Interface (API ). One element of the API is the ability to
run other programs.
The reason why you can click a program icon or type in a command
to run a program is that general-purpose operating systems come bundled
with a user-interface program, which uses the operating system API to run
other programs in response to mouse or keyboard input. At a marketing
level, this user-interface program may be treated as a part of the operating
system; it may not be given a prominent name of its own and may not be
available for separate purchase.
For example, Microsoft Windows comes with a user interface known
as File Explorer, which provides features such as the Start menu and the
ability to click icons. (This program was named Windows Explorer prior to
Windows 8.) However, even if you are an experienced Windows user, you
may never have heard of File Explorer; Microsoft has chosen to give it a
very low profile, treating it as an integral part of the Microsoft Windows
environment. At a technical level, however, it is distinct from the operating
system proper. In order to make the distinction explicit, the true operating
system is often called the kernel. The kernel is the fundamental portion
of Microsoft Windows that provides an API supporting computations with
controlled interactions.
A similar distinction between the kernel and the user interface applies
to Linux. The Linux kernel provides the basic operating system services
through an API, whereas shells are the programs (such as bash and tcsh)
that interpret typed commands, and desktop environments are the programs,
such as KDE (K Desktop Environment) and GNOME, that handle graphical
interaction.
In this book, I will explain the workings of operating system kernels,
the true operating systems themselves, as opposed to the user-interface pro-
grams. One reason is because user-interface programs are not constructed
in any fundamentally different way than normal application programs. The
6 CHAPTER 1. INTRODUCTION

other reason is because an operating system need not have this sort of user
interface at all. Consider again the case of an embedded system that con-
trols automotive fuel injection. If the system is sufficiently sophisticated,
it may include an operating system. The main control program may run
other, more specialized programs. However, there is no ability for the user
to start an arbitrary program running through a shell or desktop environ-
ment. In this book, I will draw my examples from general-purpose systems
with which you might be familiar, but will emphasize the principles that
could apply in other contexts as well.

1.3 What Is Middleware?

Now that you know what an operating system is, I can turn to the other cat-
egory of software covered by this book: middleware. Middleware is software
occupying a middle position between application programs and operating
systems, as I will explain in this section.
Operating systems and middleware have much in common. Both are
software used to support other software, such as the application programs
you run. Both provide a similar range of services centered around con-
trolled interaction. Like an operating system, middleware may enforce rules
designed to keep the computations from interfering with one another. An
example is the rule that only one computation may modify a shared data
structure at a time. Like an operating system, middleware may bring com-
putations at different times into contact through persistent storage and may
support interaction between computations on different computers by pro-
viding network communication services.
Operating systems and middleware are not the same, however. They
rely upon different underlying providers of lower-level services. An operat-
ing system provides the services in its API by making use of the features
supported by the hardware. For example, it might provide API services
of reading and writing named, variable-length files by making use of a disk
drive’s ability to read and write numbered, fixed-length blocks of data. Mid-
dleware, on the other hand, provides the services in its API by making use
of the features supported by an underlying operating system. For example,
the middleware might provide API services for updating relational database
tables by making use of an operating system’s ability to read and write files
that contain the database.
This layering of middleware on top of an operating system, as illustrated
in Figure 1.2, explains the name; middleware is in the middle of the vertical
1.3. WHAT IS MIDDLEWARE? 7

stack, between the application programs and the operating system. Viewed
horizontally rather than vertically, middleware is also in the middle of in-
teractions between different application programs (possibly even running
on different computer systems), because it provides mechanisms to support
controlled interaction through coordination, persistent storage, naming, and
communication.
I already mentioned relational database systems as one example of mid-
dleware. Such systems provide a more sophisticated form of persistent stor-
age than the files supported by most operating systems. I use Oracle as my
primary source of examples regarding relational database systems. Other
middleware I will use for examples in the book includes the Java 2 Plat-
form, Enterprise Edition (J2EE) and IBM’s WebSphere MQ. These systems
provide support for keeping computations largely isolated from undesirable
interactions, while allowing them to communicate with one another even if
running on different computers.
The marketing definition of middleware doesn’t always correspond ex-
actly with my technical definition. In particular, some middleware is of
such fundamental importance that it is distributed as part of the operat-
ing system bundle, rather than as a separate middleware product. As an
example, general-purpose operating systems all come equipped with some
mechanism for translating Internet hostnames, such as www.gustavus.edu,
into numerical addresses. These mechanisms are typically outside the oper-
ating system kernel, but provide a general supporting service to application
programs. Therefore, by my definition, they are middleware, even if not
normally labeled as such.

Application Application Application

Middleware Middleware

Database
Operating System Table Operating System

Figure 1.2: Middleware uses services from an operating system and in turn
provides services to application programs to support controlled interaction.
8 CHAPTER 1. INTRODUCTION

1.4 Objectives for the Book

If you work your way through this book, you will gain both knowledge
and skills. Notice that I did not say anything about reading the book, but
rather about working your way through the book. Each chapter in this book
concludes with exercises, programming projects, exploration projects, and
some bibliographic or historical notes. To achieve the objectives of the book,
you need to work exercises, carry out projects, and occasionally venture
down one of the side trails pointed out by the end-of-chapter notes. Some of
the exploration projects will specifically direct you to do research in outside
sources, such as on the Internet or in a library. Others will call upon you to
do experimental work, such as measuring the performance consequences of
a particular design choice. If you are going to invest that kind of time and
effort, you deserve some idea of what you stand to gain from it. Therefore, I
will explain in the following paragraphs how you will be more knowledgeable
and skilled after finishing the book.
First, you will gain a general knowledge of how contemporary operat-
ing systems and middleware work and some idea why they work that way.
That knowledge may be interesting in its own right, but it also has prac-
tical applications. Recall that these systems provide supporting APIs for
application programmers to use. Therefore, one payoff will be that if you
program applications, you will be positioned to make more effective use of
the supporting APIs. This is true even though you won’t be an expert at
any particular API; instead, you’ll see the big picture of what services those
APIs provide.
Another payoff will be if you are in a role where you need to alter the
configuration of an operating system or middleware product in order to tune
its performance or make it best serve a particular context. Again, this one
book alone won’t give you all the specific knowledge you need about any
particular system, but it will give you the general background to make sense
out of more specialized references.
Perhaps the most significant payoff for learning the details of today’s
systems in the context of the reasons behind their designs is that you will
be in a better position to learn tomorrow’s systems. You will be able to see
in what ways they are different and in what ways they are fundamentally
still the same. You will be able to put new features into context, often as
a new solution to an old problem, or even just as a variant on an existing
solution. If you really get excited by what you learn from this book, you
could even use your knowledge as the foundation for more advanced study
and become one of the people who develops tomorrow’s systems.
1.5. MULTIPLE COMPUTATIONS ON ONE COMPUTER 9

Second, in addition to knowledge about systems, you will learn some

skills that are applicable even outside the context of operating systems and
middleware. Some of the most important skills come from the exploration
projects. For example, if you take those projects seriously, you’ll practice
not only conducting experiments, but also writing reports describing the
experiments and their results. That will serve you well in many contexts.
I have also provided you with some opportunities to develop proficiency
in using the professional literature, such as documentation and the papers
published in conference proceedings. Those sources go into more depth than
this book can, and they will always be more up-to-date.
From the programming projects, you’ll gain some skill at writing pro-
grams that have several interacting components operating concurrently with
one another and that keep their interactions under control. You’ll also de-
velop some skill at writing programs that interact over the Internet. In
neither case will you become a master programmer. However, in both cases,
you will be laying a foundation of skills that are relevant to a range of
development projects and environments.
Another example of a skill you can acquire is the ability to look at the
security ramifications of design decisions. I have a security section in each
chapter, rather than a security chapter only at the end of the book, because I
want you to develop the habit of asking, “What are the security issues here?”
That question is relevant even outside the realm of operating systems and
middleware.
As I hope you can see, studying operating systems and middleware can
provide a wide range of benefits, particularly if you engage yourself in it as
an active participant, rather than as a spectator. With that for motivation,
I will now take you on another tour of the services operating systems and
middleware provide. This tour is more detailed than Sections 1.2 and 1.3,
but not as detailed as Chapters 2 through 11.

1.5 Multiple Computations on One Computer

The single most fundamental service an operating system provides is to allow
multiple computations to be going on at the same time, rather than forcing
each to wait until the previous one has run to completion. This allows
desktop computers to juggle multiple tasks for the busy humans seated in
front of their screens, and it allows server computers to be responsive to
requests originating from many different client computers on the Internet.
Beyond these responsiveness concerns, concurrent computations can also
10 CHAPTER 1. INTRODUCTION

make more efficient use of a computer’s resources. For example, while one
computation is stalled waiting for input to arrive, another computation can
be making productive use of the processor.
A variety of words can be used to refer to the computations underway
on a computer; they may be called threads, processes, tasks, or jobs. In this
book, I will use both the word “thread” and the word “process,” and it is
important that I explain now the difference between them.
A thread is the fundamental unit of concurrency. Any one sequence of
programmed actions is a thread. Executing a program might create multiple
threads, if the program calls for several independent sequences of actions run
concurrently with one another. Even if each execution of a program creates
only a single thread, which is the more normal case, a typical system will be
running several threads: one for each ongoing program execution, as well as
some that are internal parts of the operating system itself.
When you start a program running, you are always creating one or more
threads. However, you are also creating a process. The process is a container
that holds the thread or threads that you started running and protects
them from unwanted interactions with other unrelated threads running on
the same computer. For example, a thread running in one process cannot
accidentally overwrite memory in use by a different process.
Because human users normally start a new process running every time
they want to make a new computation happen, it is tempting to think of
processes as the unit of concurrent execution. This temptation is ampli-
fied by the fact that older operating systems required each process to have
exactly one thread, so that the two kinds of object were in one-to-one corre-
spondence, and it was not important to distinguish them. However, in this
book, I will consistently make the distinction. When I am referring to the
ability to set an independent sequence of programmed actions in motion, I
will write about creating threads. Only when I am referring to the ability
to protect threads will I write about creating processes.
In order to support threads, operating system APIs include features such
as the ability to create a new thread and to kill off an existing thread. In-
side the operating system, there must be some mechanism for switching
the computer’s attention between the various threads. When the operating
system suspends execution of one thread in order to give another thread a
chance to make progress, the operating system must store enough informa-
tion about the first thread to be able to successfully resume its execution
later. Chapter 2 addresses these issues.
Some threads may not be runnable at any particular time, because they
are waiting for some event, such as the arrival of input. However, in general,
1.6. INTERACTIONS BETWEEN COMPUTATIONS 11

an operating system will be confronted with multiple runnable threads and

will have to choose which ones to run at each moment. This problem of
scheduling threads’ execution has many solutions, which are surveyed in
Chapter 3. The scheduling problem is interesting, and has generated so
many solutions, because it involves the balancing of system users’ competing
interests and values. No individual scheduling approach will make everyone
happy all the time. My focus is on explaining how the different scheduling
approaches fit different contexts of system usage and achieve differing goals.
In addition I explain how APIs allow programmers to exert control over
scheduling, for example, by indicating that some threads should have higher
priority than others.

1.6 Controlling the Interactions Between Compu-

tations
Running multiple threads at once becomes more interesting if the threads
need to interact, rather than execute completely independently of one an-
other. For example, one thread might be producing data that another thread
consumes. If one thread is writing data into memory and another is read-
ing the data out, you don’t want the reader to get ahead of the writer and
start reading from locations that have yet to be written. This illustrates one
broad family of control for interaction: control over the relative timing of
the threads’ execution. Here, a reading step must take place after the cor-
responding writing step. The general name for control over threads’ timing
is synchronization.
Chapter 4 explains several common synchronization patterns, includ-
ing keeping a consumer from outstripping the corresponding producer. It
also explains the mechanisms that are commonly used to provide synchro-
nization, some of which are supported directly by operating systems, while
others require some modest amount of middleware, such as the Java runtime
environment.
That same chapter also explains a particularly important difficulty that
can arise from the use of synchronization. Synchronization can force one
thread to wait for another. What if the second thread happens to be wait-
ing for the first? This sort of cyclic waiting is known as a deadlock. My
discussion of ways to cope with deadlock also introduces some significant
middleware, because database systems provide an interesting example of
deadlock handling.
In Chapter 5, I expand on the themes of synchronization and middleware
12 CHAPTER 1. INTRODUCTION

by explaining transactions, which are commonly supported by middleware.

A transaction is a unit of computational work for which no intermediate
state from the middle of the computation is ever visible. Concurrent trans-
actions are isolated from seeing each other’s intermediate storage. Addi-
tionally, if a transaction should fail, the storage will be left as it was before
the transaction started. Even if the computer system should catastroph-
ically crash in the middle of a transaction’s execution, the storage after
rebooting will not reflect the partial transaction. This prevents results of a
half-completed transaction from becoming visible. Transactions are incred-
ibly useful in designing reliable information systems and have widespread
commercial deployment. They also provide a good example of how mathe-
matical reasoning can be used to help design practical systems; this will be
the chapter where I most prominently expect you to understand a proof.
Even threads that have no reason to interact may accidentally interact, if
they are running on the same computer and sharing the same memory. For
example, one thread might accidentally write into memory being used by the
other. This is one of several reasons why operating systems provide virtual
memory, the topic of Chapter 6. Virtual memory refers to the technique of
modifying addresses on their way from the processor to the memory, so that
the addresses actually used for storing values in memory may be different
from those appearing in the processor’s load and store instructions. This
is a general mechanism provided through a combination of hardware and
operating system software. I explain several different goals this mechanism
can serve, but the most simple is isolating threads in one process from those
in another by directing their memory accesses to different regions of memory.
Having broached the topic of providing processes with isolated virtual
memory, I devote Chapter 7 to processes. This chapter explains an API
for creating processes. However, I also focus on protection mechanisms, not
only by building on Chapter 6’s introduction of virtual memory, but also by
explaining other forms of protection that are used to protect processes from
one another and to protect the operating system itself from the processes.
Some of these protection mechanisms can be used to protect not just the
storage of values in memory, but also longer-term data storage, such as files,
and even network communication channels. Therefore, Chapter 7 lays some
groundwork for the later treatment of these topics.
Chapter 7 also provides me an opportunity to clarify one point about
threads left open by Chapter 2. By showing how operating systems pro-
vide a protective boundary between themselves and the running application
processes, I can explain where threads fall relative to this boundary. In par-
ticular, there are threads that are contained entirely within the operating
1.7. SUPPORTING INTERACTION ACROSS TIME 13

system kernel, others that are contained entirely within an application pro-
cess, and yet others that cross the boundary, providing support from within
the kernel for concurrent activities within the application process. Although
it might seem natural to discuss these categories of threads in Chapter 2, the
chapter on threads, I really need to wait for Chapter 7 in order to make any
more sense out of the distinctions than I’ve managed in this introductory
paragraph.
When two computations run concurrently on a single computer, the hard
part of supporting controlled interaction is to keep the interaction under con-
trol. For example, in my earlier example of a pair of threads, one produces
some data and the other consumes it. In such a situation, there is no great
mystery to how the data can flow from one to the other, because both are
using the same computer’s memory. The hard part is regulating the use of
that shared memory. This stands in contrast to the interactions across time
and space, which I will address in Sections 1.7 and 1.8. If the producer and
consumer run at different times, or on different computers, the operating
system and middleware will need to take pains to convey the data from one
to the other.

1.7 Supporting Interaction Across Time

General purpose operating systems all support some mechanism for com-
putations to leave results in long-term storage, from which they can be
retrieved by later computations. Because this storage persists even when
the system is shut down and started back up, it is known as persistent stor-
age. Normally, operating systems provide persistent storage in the form of
named files, which are organized into a hierarchy of directories or folders.
Other forms of persistent storage, such as relational database tables and
application-defined persistent objects, are generally supported by middle-
ware. In Chapter 8, I focus on file systems, though I also explain some of
the connections with middleware. For example, I compare the storage of file
directories with that of database indexes. This comparison is particularly
important as these areas are converging. Already the underlying mecha-
nisms are very similar, and file systems are starting to support indexing
services like those provided by database systems.
There are two general categories of file APIs, both of which I cover in
Chapter 8. The files can be made a part of the process’s virtual mem-
ory space, accessible with normal load and store instructions, or they can
be treated separately, as external entities to read and write with explicit
14 CHAPTER 1. INTRODUCTION

operations.
Either kind of file API provides a relatively simple interface to some quite
significant mechanisms hidden within the operating system. Chapter 8 also
provides a survey of some of these mechanisms.
As an example of a simple interface to a sophisticated mechanism, an
application programmer can make a file larger simply by writing additional
data to the end of the file. The operating system, on the other hand, has
to choose the location where the new data will be stored. When disks are
used, this space allocation has a strong influence on performance, because
of the physical realities of how disk drives operate.
Another job for the file system is to keep track of where the data for each
file is located. It also keeps track of other file-specific information, such as
access permissions. Thus, the file system not only stores the files’ data, but
also stores metadata, which is data describing the data.
All these mechanisms are similar to those used by middleware for pur-
poses such as allocating space to hold database tables. Operating systems
and middleware also store information, such as file directories and database
indexes, used to locate data. The data structures used for these naming and
indexing purposes are designed for efficient access, just like those used to
track the allocation of space to stored objects.
To make the job of operating systems and middleware even more chal-
lenging, persistent storage structures are expected to survive system crashes
without significant loss of integrity. For example, it is not acceptable after
a crash for specific storage space to be listed as available for allocation and
also to be listed as allocated to a file. Such a confused state must not occur
even if the crash happened just as the file was being created or deleted.
Thus, Chapter 8 builds on Chapter 5’s explanation of atomic transactions,
while also outlining some other mechanisms that can be used to protect the
integrity of metadata, directories, and indexes.
Persistent storage is crucially important, perhaps even more so in the
Internet age than in prior times, because servers now hold huge amounts of
data for use by clients all over the world. Nonetheless, persistent storage no
longer plays as unique a role as it once did. Once upon a time, there were
many computer systems in which the only way processes communicated was
through persistent storage. Today, that is almost unthinkable, because com-
munication often spans the Internet. Therefore, as I explain in Section 1.8,
operating systems provide support for networking, and middleware provides
further support for the construction of distributed systems.
1.8. SUPPORTING INTERACTION ACROSS SPACE 15

1.8 Supporting Interaction Across Space

In order to build coherent software systems with components operating on
differing computers, programmers need to solve lots of problems. Consider
two examples: data flowing in a stream must be delivered in order, even
if sent by varying routes through interconnected networks, and message
delivery must be incorporated into the all-or-nothing guarantees provided
by transactions. Luckily, application programmers don’t need to solve most
of these problems, because appropriate supporting services are provided by
operating systems and middleware.
I divide my coverage of these services into two chapters. Chapter 9 pro-
vides a foundation regarding networking, so that this book will stand on
its own if you have not previously studied networking. That chapter also
covers services commonly provided by operating systems, or in close conjunc-
tion with operating systems, such as distributed file systems. Chapter 10,
in contrast, explains the higher-level services that middleware provides for
application-to-application communication, in such forms as messaging and
web services. Each chapter introduces example APIs that you can use as an
application programmer, as well as the more general principles behind those
specific APIs.
Networking systems, as I explain in Chapter 9, are generally partitioned
into layers, where each layer makes use of the services provided by the layer
under it in order to provide additional services to the layer above it. At the
bottom of the stack is the physical layer, concerned with such matters as
copper, fiber optics, radio waves, voltages, and wavelengths. Above that is
the link layer, which provides the service of transmitting a chunk of data to
another computer on the same local network. This is the point where the op-
erating system becomes involved. Building on the link-layer foundation, the
operating system provides the services of the network layer and the transport
layer. The network layer arranges for data to be relayed through intercon-
nected networks so as to arrive at a computer that may be elsewhere in the
world. The transport layer builds on top of this basic computer-to-computer
data transmission to provide more useful application-to-application commu-
nication channels. For example, the transport layer typically uses sequence
numbering and retransmission to provide applications the service of in-order,
loss-free delivery of streams of data. This is the level of the most common
operating system API, which provides sockets, that is, endpoints for these
transport-layer connections.
The next layer up is the application layer. A few specialized application-
layer services, such as distributed file systems, are integrated with operating
16 CHAPTER 1. INTRODUCTION

systems. However, most application-layer software, such as web browsers

and email programs, is written by application programmers. These applica-
tions can be built directly on an operating system’s socket API and exchange
streams of bytes that comply with standardized protocols. In Chapter 9, I
illustrate this possibility by showing how web browsers and web servers
communicate.
Alternatively, programmers of distributed applications can make use of
middleware to work at a higher level than sending bytes over sockets. I show
two basic approaches to this in Chapter 10: messaging and Remote Proce-
dure Calls (RPCs). Web services are a particular approach to standardizing
these kinds of higher-level application communication, and have often been
used with RPCs.
In a messaging system, an application program requests the delivery of a
message. The messaging system not only delivers the message, which lower-
level networking could accomplish, but also provides additional services. For
example, the messaging is often integrated with transaction processing. A
successful transaction may retrieve a message from an incoming message
queue, update a database in response to that message, and send a response
message to an outgoing queue. If the transaction fails, none of these three
changes will happen; the request message will remain in the incoming queue,
the database will remain unchanged, and the response message will not be
queued for further delivery. Another common service provided by messag-
ing systems is to deliver a message to any number of recipients who have
subscribed to receive messages of a particular kind; the sender need not be
aware of who the actual receivers are.
Middleware can also provide a mechanism for Remote Procedure Call
(RPC ), in which communication between a client and a server is made to
look like an ordinary programming language procedure call, such as invoking
a method on an object. The only difference is that the object in question is
located on a different computer, and so the call and return involve network
communication. The middleware hides this complexity, so that the applica-
tion programmer can work largely as though all the objects were local. In
Chapter 10, I explain this concept more fully and mention that it is often
used in the form of web services. A web service is an application-layer entity
that programs can communicate with using standardized protocols similar
to those humans use to browse the web.
1.9. SECURITY 17

1.9 Security
Operating systems and middleware are often the targets of attacks by ad-
versaries trying to defeat system security. Even attacks aimed at application
programs often relate to operating systems and middleware. In particular,
easily misused features of operating systems and middleware can be the
root cause of an application-level vulnerability. On the other hand, operat-
ing systems and middleware provide many features that can be very helpful
in constructing secure systems.
A system is secure if it provides an acceptably low risk that an adversary
will prevent the system from achieving its owner’s objectives. In Chapter 11,
I explain in more detail how to think about risk and about the conflicting
objectives of system owners and adversaries. In particular, I explain that
some of the most common objectives for owners fall into four categories:
confidentiality, integrity, availability, and accountability. A system provides
confidentiality if it prevents inappropriate disclosure of information, integrity
if it prevents inappropriate modification or destruction of information, and
availability if it prevents inappropriate interference with legitimate usage. A
system provides accountability if it provides ways to check how authorized
users have exercised their authority. All of these rely on authentication, the
ability of a system to verify the identity of a user.
Many people have a narrow view of system security. They think of those
features that would not even exist, were it not for security issues. Clearly,
logging in with a password (or some other, better form of authentication) is
a component of system security. Equally clearly, having permission to read
some files, but not others, is a component of system security, as are crypto-
graphic protocols used to protect network communication from interception.
However, this view of security is dangerously incomplete.
You need to keep in mind that the design of any component of the
operating system can have security consequences. Even those parts whose
design is dominated by other considerations must also reflect some proactive
consideration of security consequences, or the overall system will be insecure.
In fact, this is an important principle that extends beyond the operating
system to include application software and the humans who operate it.
Therefore, I will make a habit of addressing security issues in every
chapter, rather than only at the end of the book. Specifically, each chapter
concludes with a section pointing out some of the key security issues asso-
ciated with that chapter’s topic. I also provide a more coherent treatment
of security by concluding the book as a whole with Chapter 11, which is
devoted exclusively to security. That chapter takes a holistic approach to
18 CHAPTER 1. INTRODUCTION

security, in which human factors play as important a role as technical ones.

Exercises
1.1 What is the difference between an operating system and middleware?

1.2 What do operating systems and middleware have in common?

1.3 What is the relationship between threads and processes?

1.4 What is one way an operating system might isolate threads from un-
wanted interactions, and what is one way that middleware might do
so?

1.5 What is one way an operating system might provide persistent storage,
and what is one way middleware might do so?

1.6 What is one way an operating system might support network commu-
nication, and what is one way middleware might do so?

1.7 Of all the topics previewed in this chapter, which one are you most
looking forward to learning more about? Why?

Programming Project
1.1 Write, test, and debug a program in the language of your choice to
carry out any task you choose. Then write a list of all the services
you suspect the operating system is providing in order to support the
execution of your sample program. If you think the program is also
relying on any middleware services, list those as well.

Exploration Projects
1.1 Look through the titles of the papers presented at several recent con-
ferences hosted by the USENIX Association (The Advanced Comput-
ing Systems Association); you can find the conference proceedings at
www.usenix.org. To get a better idea what an individual paper is
about, click the title to show the abstract, which is a short summary
of the paper. Based on titles and abstracts, pick out a few papers that
you think would make interesting supplementary reading as you work
1.9. SECURITY 19

your way through this book. Write down a list showing the biblio-
graphic information for the papers you selected and, as near as you
can estimate, where in this book’s table of contents they would be
appropriate to read.

1.2 Conduct a simple experiment in which you take some action on a

computer system and observe what the response is. You can choose
any action you wish and any computer system for which you have
appropriate access. You can either observe a quantitative result, such
as how long the response takes or how much output is produced, or
a qualitative result, such as in what form the response arrives. Now,
try replicating the experiment. Do you always get the same result?
Similar ones? Are there any factors that need to be controlled in
order to get results that are at least approximately repeatable? For
example, to get consistent times, do you need to reboot the system
between each trial and prevent other people from using the system?
To get consistent output, do you need to make sure input files are
kept unchanged? If your action involves a physical device, such as a
printer, do you have to control variables such as whether the printer
is stocked with paper? Finally, write up a careful report, in which
you explain both what experiment you tried and what results you
observed. You should explain how repeatable the results proved to be
and what limits there were on the repeatability. You should describe
the hardware and software configuration in enough detail that someone
else could replicate your experiment and would be likely to get similar
results.

Notes
The idea that an operating system should isolate computations from un-
wanted interactions, and yet support desirable interactions, has a long her-
itage. A 1962 paper [38] by Corbató, Daggett, and Daley points out that
“different user programs if simultaneously in core memory may interfere with
each other or the supervisor program so some form of memory protection
mode should be available when operating user programs.” However, that
same paper goes on to say that although “great care went into making each
user independent of the other users . . . it would be a useful extension of the
system if this were not always the case,” so that the computer system could
support group work, such as war games.
20 CHAPTER 1. INTRODUCTION

Middleware is not as well-known to the general public as operating sys-

tems are, though commercial information-system developers would be lost
without it. One attempt to introduce middleware to a somewhat broader
audience was Bernstein’s 1996 survey article [17].
The USENIX Association, mentioned in Exploration Project 1.1, is only
one of several very fine professional societies holding conferences related to
the subject matter of this book. The reason why I specifically recommended
looking through their proceedings is that they tend to be particularly ac-
cessible to students. In part this is because USENIX focuses on bringing
practitioners and academics together; thus, the papers generally are prag-
matic without being superficial. The full text is available on their website.
Other documents randomly have
different content
ja kaikki kappaleet olivat samaa laatua ja kokoa. Ne olivat pitkiä ja
kapeita, ruumisarkun näköisiä.

— Vai niin! sanoi Chimb ja katseli kysyvästi meihin neljään, jotka

myös istuimme juorupiirissä. — Ymmärrättekö asian, pojat?

— Ymmärrämme, sanoimme.

— Nuo kuivettuneet raukat eivät siis päässeetkään taivaalliseen

Kiinaan vetämään iankaikkista untaan, sanoi Chimb.

Asia oli hyvin ymmärrettävä: ruumiinkuljetuslaiva oli etukäteen

saanut tavattoman suuren rahtimaksun. Kippari-roisto oli sitä mieltä,
että kiinalaiset vainajat valtameren syvimmässä paikassa ovat
lähempänä helvettiä kuin Kiinan mullassa. Kukapa kipparin
vastuuseen saattaisi! Maailmahan on suuri.

— Tietenkin se kiinalainen, joka oli laivassa huolehtimassa

vainajien kotiinpaluumatkasta, ensin sai katsella, kuinka lasti
purettiin mereen, ja sitten seurata itse perästä, sanoi Chimb.

— Tämä on kauheata. Voi miesparkaani! sanoi mrs. Fiddler ja sai

lievän kohtauksen.

— Rauhoittukaa, rouva! Ei miehenne tule kosketuksiin noiden

kanssa.
Maapallolla on enemmän merta kuin maata, Chimb sanoi.

Aika rientää. Emme ole kauan enää tällä kolkolla rannikolla. Ei

meillä täällä tosin ole ollut mitään hätää — päinvastoin. Mutta toista
on sentään olla Etelä-Amerikan itärannikolla, johon pasaadi Atlantilta
tuo raikkaan ihanan merituulen, ja missä kultainen kuningatar
aurinko noustuaan merikylvystään sanoo hyvää huomenta. Tätä
näkyä ei ole suotu niille, jotka oleskelevat täällä. Perun kansaa en
moiti enkä Perun hallitusmiehiäkään, päinvastoin kiitän.

Rose Fiddler on lähtövalmis. Sen päällikkö on Thomas Scott.

Ensimmäiseksi upseeriksi Columbiassa on koroitettu sen entinen
toinen upseeri, australialainen Robert Rogers, ja toisen upseerin
toimi on uskottu minulle. Chimb on lunastanut ryövärilaivan päällikön
"calabussista" ja tämä on saanut takaisin revolverinsa. Rose Fiddler
saapuu Eurooppaan luultavasti ennemmin kuin Columbia, jossa sitä
paitsi rupeaa olemaan ahdasta, mrs. Fiddlerin ja Lelun jäädessä
siihen. Sen vuoksi signor Americo Pedro jatkaa matkaansa Rose
Fiddlerillä.

Saatoimme joukolla Americo Pedron Rose Fiddleriin sen

lähtöpäivän aamuna. Sinne oli saapunut ystävällisiä saattajia ja
auttajia Huanillasin laivastosta, ja toisia tuli, kun laskimme
paraatirapun luo. Ei kuulunut kirouksia eikä huutoa kuten ennen,
Rose Fiddlerin ollessa ryövärilaivana. Entiset ryöväriupseerit,
puettuina maihinmenovaatteisiinsa, liikkuivat melkein ääneti ja
puhuivat hiljaisesti vähät puhuttavansa. Mrs. Fiddler oli luonnollisesti
jäänyt Columbiaan. Kajuutan etupuolelle ovat kokoontuneet Americo
Pedron ympärille Chimb, John Stonefied ja Andrew Kelly.

— Te kiititte, signor Pedro, minua siitä, että tulin ampumapaikalle

vapauttamaan teidät tuosta hirveästä… Mutta minä kiitän teitä siitä,
että odotitte. Ja meidän tulee kaikkien kiittää kultaista aurinkoa, joka
hetkeksi seisahdutti kulkunsa ja jo metsän taa vaivuttuaan loi
heijastuksensa minun hattuuni, sanoi Chimb.

John Stonefield otti Signor Pedron käden ja puristi sitä niin kovaa,
että tämä huudahti.
 — Toivon, että aina muistatte tämän kädenpuristuksen.

Andrew Kelly, köyhä irlantilainen, laskeutui polvilleen Americo

Pedron eteen.

— Jumala teitä seuratkoon! Kun tulette Queenstowniin, niin

sanokaa ystävilleni siellä, että Andrew ei ole enää koira.

Signor Pedron saattaessa Chimbiä veneeseen antoi Chimb hänelle

paketin, joka sisälsi upseerien revolverit: — Antakaa nämä
asianomaisille.
XIII.

Meillä on lähtöpäivä. Kello on jo kaksitoista, mutta molemmat

ankkurit ovat vielä pohjassa. Ystävät olivat tulleet kahdeksan aikana
Columbiaan auttamaan sitä matkaan, mutta maanjäristyksen vuoksi
heidän oli pakko mennä takaisin laivoihinsa. Tämä oli kolmas
kovempi järistys Huanillasissa oloaikanamme. Se olisi voinut olla
meille vaarallinen, jos hyökyaalto olisi tullut ankkurien ollessa irti
pohjasta. Kahdentoista jälkeen palasivat naapurit, ja kello neljä
jätimme Huanillasin. Andit ja merenpohja olivat antaneet meille
jäähyväistärähdyksen. Tämä oli ainoa maanjäristys päiväiseen aikaan
Huanillasissa ollessamme.

Columbia kyntää syvään lastattuna etelää kohti.

Guano on raskasta ainetta. Sitä voi lastata laivan ruumaan vain

puolet tai korkeintaan kaksi kolmatta osaa siitä, mitä ruumaan
mahtuisi. Jottei laiva tulisi kiipperäksi luodaan guano laivan ruumaan
siten, että se muodostaa selänteen eli harjun. Guano ei siis saa
maata vaakasuorassa tasossa seinästä seinään.

Kun sekä perä- että kokkapuolella oli syöty viimeinen yhteinen

ateria, asetettiin merivahti. Tämä tapahtuu siten, että kaikkien
miesten seisoessa rivissä kapteeni ja ensimmäinen upseeri vuoron
perään valitsevat yhden miehen kerrassaan vahtiinsa, niin kauan
kuin miehiä riittää. Kapteenilla on etuoikeus valita ensimmäiseksi.
Täten tulee miehistö jaetuksi kahteen yhtä suureen osaan, ylä- ja
alahangan vahtiin. Ylähanganvahdin päällikkö on kapteeni, ja
alahangan vahdin ensimmäinen upseeri.

Kello kahdeksan lyötiin kahdeksan lasia, jolloin ylähangan vahti

otti laivan huostaansa ja alahangan vahti sai mennä nukkumaan.
Kun kello on kaksitoista — kahdeksan lasia — nousee alahangan
vahti kannelle ja ottaa vahdinpidon, jolloin toinen vahti menee alas.
Tätä peliä — neljä tuntia kannella, neljä tuntia vapaana, niin yöllä
kuin päivällä jatkuu sitten niin kauan kuin laiva on purjeiden alla.
Seuraavana päivänä kello puoli kaksitoista seisoimme me kolme
koulittua purjehtijaa kajuutan katolla sekstantit kädessä ja
kiikaroimme tuon tuostakin aurinkoa. Keskipäivällä sai ruorimies
määräyksen lyödä kahdeksan lasia, jolloin kello pantiin
kahdelletoista. Vanha vuorokausi — 24 tuntia — oli päättynyt ja uusi
alkoi (kello 12 päivällä).

Pian oli leveysaste laskettu. Kun annoin peräsimessä seisovalle

Fredille uuden kurssin, sanoi hän, toistettuansa saamansa kurssin,
vilkaistuaan kompassia ja pyöräytettyään pari kierrosta
peräsinpyörää:

— Jumalan kiitos, että ollaan taas vetten päällä! Onpa siitä aikoja
kun kynnin valtameren selkää. Kauankohan tätä lystiä kestää!?

Chimb ja Teresia olivat tulleet kompassihuoneen luo ja rouva

Fiddler istui telttatuolilla kapeassa käytävässä reilingin ja kajuutan
seinän välissä. Olimme tekemisissä kaakkoispasaadin kanssa ja
matkalla etelään päin. Laiva kulki hiukan kallellaan. Siinä syy, miksi
rouva ei istunut suojapuolen reilingin luona: hän pelkäsi laivan
kaatuvan.

— Tule tänne sinäkin, Lelu, ettet suotta kallista laivaa, hän sanoi
tytölle, joka noustuaan ylös kajuutasta aikoi mennä suojan puolelle.

— Fred kysyi taannoin, kuinka kauan tätä lystiä mahtaa kestää?

Voitteko arvata, mr. West, kuinka pian voimme saapua Britanniaan,
ja sanoa, kuinka pitkä matka sinne on? kysyi Chimb.

Tähän vastasin:

— Mahdotonta tietää, kuinka kauan matka kestää, se riippuu

tuulista ja ilmoista. Matkan pituus on parinkymmenen tuhannen
virstan paikoilla. Sen tien pituutta, jota kuljemme, on mahdoton
arvata edeltäpäin, sillä laivamme saa niin kuin muutkin joka päivä
pituus- ja leveysasteen laskun mukaan oikaista suuntaansa.

Ei merenkävijä pysy kurssissaan niin kuin maalla kulkija. Laivaa

vievät tuuli, aallot ja merivirrat pois siitä kurssista, jota se kompassin
mukaan on pitävinään. Mitä myötäisempi tuuli, sen enemmän
purjehdittu kurssi pitää yhtä ohjatun kanssa. Jos taas tuuli on
vastainen, ja on luovittava, voi käydä niin, että matkaa tehdään
paljonkin, mutta määräpaikka lähenee hitaasti — ehkä ei laisinkaan.
Voi käydä niinkin, että kuljetaan takaperin.

— Kuinkahan pitkä matka on tästä Kap Horniin? kysyi rouva.

— Noin viisituhatta virstaa, vastasin.

— Tuuli tuntuu kiihtyvän. Ei ole skantäkin lista kaukana

vedenrajasta. Eiköhän olisi aika vähentää purjeita? Buuvenpramitkin
ovat vielä päällä, sanoi rouva.
 — Kyllä kapteeni siitä huolen pitää, hän on itse kannella, sanoin.

— Niinhän tuo on. Eihän tämä laiva tosiaan olekaan minun.

Pasaadissa ei ole koskaan myrskyä, mutta voi sentään tuulia

niinkin navakasti, että buuvenpramit on otettava alas, vieläpä
pramitkin. Ensin mainitut otettiinkin kohta alas ja moni olisi ottanut
viimeksi mainitutkin. Kurssin muututtua vähän itäisemmäksi oli tuuli
tullut täpärämmäksi ja raakapuut ja skuutit vedetyksi niin kiinteälle
kuin mahdollista. Tämän johdosta Columbia vuoroin kohotti
kokkaansa, vuoroin kallisti sitä mereen, jolloin meri roiskautti yli
laivan. Tämä ei vanhalle merimiehelle merkitse mitään, etenkin kun
pasaadivesi on lämmintä. Hän vain sanoo leikillisesti:

— Häpeä vähän, ettäs syljet silmilleni!

Eivät matkustajat eivätkä ensikertalaiset meripojatkaan juuri ota

pahakseen, että meri sylkee heitä vasten kasvoja. Mutta sitä, että
laiva tämän laatuisissa liikkeissään viskelee edestakaisin heidän
vatsassaan olevaa lastia, he eivät siedä.

Tämähän oli monen kuukauden perästä ensimmäinen vatsalastin

viskeleminen. Huomasin, että naisten kasvot vaalenivat.

— Eiköhän olisi parasta, että naiset menisivät pois kannelta

kastumasta, sanoin.

— Suotta se kapteeni noin paljon pitää purjeita päällä; jos niitä

vähennettäisiin, niin ei tuo lyijykimpale niin vaivaisi sydänalaa. Mutta
toisaalta: pikemminhän päästään Kap Horniin. Siellä tapaan hänet…

Rouva Fiddler ja neiti Teresia tottuneina merellä oloon menivät

hytteihinsä.
 — Entä te, signorita?

— En tiedä, mikä olisi parempi, mennäkö alas vai jäädäkö tänne.

Olisin ennemmin täällä, mutta pelkään häpäiseväni itseni.

— Häpeästä viisi! Kohta Fred jättää peräsimensä Andrew Kellylle.

Fred löi neljä lasia — kello oli kaksi — ja ruoriin tarttui Andrew
(entinen koira)…

— Voi Neitsyt Maana, miten te näytätte huonolta, signorita, sanoi

Andrew.

Samassa Chimb-parka rupesi uhraamaan Neptunukselle. Sitten

hän kaatui suulleen ja vierähti alahangan skantäkkiä vastaan. Koetin
nostaa häntä, mutta hänen jalkansa eivät kannattaneet.
Kannettuamme hänet hyttiinsä, huomasimme, että toisiakin naisia,
Lelua lukuunottamatta, vaivasi ankara meritauti. Rouva Fiddler oli
polvillaan avonaisen kirstunsa edessä ja lattialla viruivat hänen
kalleutensa. Lelu hautoi kasvatusäitinsä päätä märällä rievulla ja
kirstuun valui vettä "ynnä muuta". Voi kurjuutta! Rupesin
pelkäämään, että rouva merikipuhulluudessaan kuvittelee olevansa
Kap Hornin kohdalla ja raahaa avuttoman Chimbinkin yli reilingin.

Keskusteltuamme kapteeni Franckin kanssa asiasta päätimme, että

joku miehistä aina olisi merisairaiden luona. Rouvan ja Teresian
merikipu meni parin päivän kuluttua ohi, mutta toista oli Chimbin.
Viikko oli jo kulunut ilman mitään paranemisen merkkiä. Sairas ei
syönyt eikä nukkunut. Hän vain makasi selällään silmät auki ja
huononi päivä päivältä. Jonkin kerran hän puoleksi tunniksi ummisti
silmänsä ja näytti silloin olevan horrostilassa. Kaikki luulivat hänen
loppunsa lähestyvän. Andrew Kelly seisoi peräsimessä purjeiden
yht'äkkiä ruvetessa elämään. Juoksin kompassihuoneen luo
katsomaan, mikä oli syy tähän — olikohan tuuli yht'äkkiä kääntynyt?
Laiva oli tykkänään pois kurssistaan ja Andrew seisoi kädet ristissä,
katse taivasta kohti, rukoillen. Tyrkkäsin hänet syrjään ja väänsin
äkkiä peräsinpyörän ympäri, joten laiva vähitellen palasi oikeaan
suuntaansa. Huusin sitten Mackin peränpitoon.

Menin sairaita katsomaan. Heidän hyttinsä oli pakaten täynnä.

Odotettiin Chimbin poislähtöä. Kaikilla oli vedet silmissä, ja
aitoenglantilainen gentlemanni Stonefield, jonka tuskin kuvitteli
osaavan vuodattaa kyyneleitä, itki kuin lapsi. Ainoastaan rouva istui
kuivin silmin ja näytti totiselta. Työnsin kaikki tieltä pois ja koetin
sairaan valtimoa. Sydän sykki heikosti, mutta sykki kuitenkin.

— Poistukaa täältä, sanoin.

Rouva vain ei liikahtanut. Otin kiinni hänen molemmista paksuista

ranteistaan ja vedin hänet pois sairaan vierestä.

— Kapteeni on hyvä ja jää tänne, että voin pyörähtää

rohtokaapilla, sanoin.

Aioin ensin mennä laivaan lääkekaapille, mutta muistin sitten, että

Chimbin matka-arkussa oli mitä tarvitsin, vieläpä tuoretta tavaraa,
eikä seisonutta kuten laiva-apteekeissa tavallisesti on. Arkku oli
lukossa, eikä ollut aikaa etsiä avainta. Varastohytissä ei näkynyt
mitään, millä olisi voinut murtaa auki kirstun kannen.

— Potkaise auki kansi! sanoin Charleylle, joka minua avusti. Sitten

annoin kapteenin ja Charleyn läsnäollessa sairaalle ruiskeen.

— Kuulkaa, kapteeni Franck! Prässätkää purjeet myötätuuleen ja

kääntäkää laiva tuulen mukaan. Sitten vähennätte purjeita, ettei
matka, jonka kuljemme suunnastamme, tule suotta liian pitkäksi.
Koetetaan tätä keinoa. Myötätuulessahan ei meritauti vaivaa
sanottavasti.

— Mahtaisiko enää vaikuttaa? Mutta signorita Chimborazon tähden

teen mitä hyvänsä, sanoi kapteeni ja pyyhki kyyneleitään. Charley
puristi kapteenin kättä ja sanoi:

— Minä maksan laivan kulungit, jos ette pane pahaksi, kapteeni

Franck.

— Niistä puhutaan sitten, sanoi kapteeni.

Jäin yksin Chimbin luo. Hän makasi silmät kiinni ja näytti

nukkuvan. Olisikohan tuo viimeisen unen ennettä, ajattelin itsekseni.
Valtimo löi hyvin hiljaa, mutta sentään säännöllisesti. Laivan liikkeet
olivat tykkänään muuttuneet. Nuo ilkeät, sydänalaa kaivavat
töyssytykset olivat poissa. Laiva vain kallisteli hiljaa ja tasaisesti
edestakaisin.

Voi sentään, etten ennemmin ehdottanut kapteenille tätä keinoa!

Kapteeni ja minä istuimme vuorotellen Chimbin luona. Oli kielletty
lyömästä lasia, ja rouva Fiddleriä oli kielletty poistumasta hytistään.
Häntä vartioitiin koko ajan. Kahdeksan aikaan seuraavana aamuna
sairaan valtimo rupesi lyömään voimakkaammin. Oli siis toivoa
paranemisesta. Nyt sai Teresia ruveta istumaan hänen luonaan.
Pasaadi oli jälleen ottanut tavallisen tahtinsa ja puhalsi hiljaa.
Vähitellen merikin rauhoittui.

— Eiköhän kohta saada kääntää kurssiamme oikeaan suuntaan,

sanoi ensimmäinen upseeri mr. Rogers, jolla oli morsian
Queenstownissa.
 — Ei, mr. Rogers; kyllä minä sanon, milloin käännytään, vastasi
kapteeni.

Pitäessäni illalla miesten kanssissa rukousta, vallitsi täällä synkkä

mieliala. Oli perjantai-ilta. Luettuani merilaissa säädetyn perjantai-
illan tekstin, sanoin miehille:

— Signorita Chimborazo paranee.

— Jumalan kiitos! sanoivat miehet hiljaisella äänellä itsekseen, ja

moni heistä pyyhki silmiään.

Andrew Kellyn, köyhän irlantilaisen, kojun seinällä riippui

ristiinnaulitun äidin kuva. Hän otti sen käteensä ja suuteli sitä.
XIV.

Olemme jo viikon verran kulkeneet oikeata suuntaa. Chimb on kuta

kuinkin toipunut. Kyllä kai hän vielä saa potea, jollei ennen, niin
myrskyisen Kap Hornin seuduilla. Hyväsydäminen, mutta hassu
rouva Fiddler oli saanut päähänsä, että jos Chimb olisi kuollut, olisi
hän mereen haudattuna viekoitellut herra Fiddlerin naimisiin
kanssaan. Tai ehkäpä vainaja olisi ryöstänyt Chimbin vastoin tämän
tahtoa. Eihän niitä miehiä tiedä…

Olemme sivuuttaneet kauriin kääntöpiirin. Hyvästi

kaakkoispasaadi, kiitos kaikesta, mitä olet antanut meille! Olemme
saaneet hengittää kuivaa terveellistä ilmaa kahden kuukauden ajan,
etkä sinä ole puhaltanut hiuksia irti päästämme. Tapaamme taas,
ellei Kap Horn pakota meitä olemaan vieraina Fiddlerin rouvan
häissä.

Olemme Etelä-Amerikan länsipuolella, ihanalla Tyynellä

valtamerellä. Kauriin kääntöpiiri kulkee länsirannikolla Antofogastan
kaupungin ja itärannikolla Rio de Janeiron yli. Tästä puoleen
tulemme tekemisiin vaihtelevaisten tuulensuuntien kanssa. Tosin
pasaadipiirin eteläpuolella voi vielä puhaltaa maatuuli, mutta se käy
vähitellen epävakaiseksi, kunnes loppuu tykkänään. Meillä on jo ollut
pieni puuska mutta ei se ole Chimbiä paljon vaivannut. Ehkä hänestä
vielä tulee "merikelpoinen".

Kauniilla säällä oleskelevat naiset — heitähän on neljä —

peräkannella. Teresia riippuu alati Chimbin käsikoukussa. Mielestäni
Chimb väliin näyttää vaivatulta, mutta koettaa salata sitä Teresialta.
Kaikki arvaavat, että tyttöä vaivaa tauti. Hän istuu mietteissään
Chimbin vieressä, puhumatta mitään. Kun Chimb irroittautuu tytöstä
hyväilläkseen Lelua, jota myös vaivaa jokin tauti — sama tauti kuin
Teresiaa — painaa Teresia päänsä Chimbin rintaa vasten, ja itku on
valmis.

Aluksi merimiehet vetivät suunsa nauruun, mutta huomattuaan,

että kapteenin tytärparka on henkisesti sairas, he surkutellen
kääntävät pois katseensa, eivätkä ole näkevinään mitään. Lelu
tavallisesti pysyttelee rouva Fiddlerin vanavedessä — tai oikeammin
tämä aina riippuu kiinni japanittaressa. Lelu on viime aikoina ottanut
tavaksensa pyörähtää etukannelle kanssin kokkapuolelle, milloin vain
ensikertalainen, Jim Peg (Peg merkitsee nappula) siellä yksinään
askaroi.

— Mitä sinä, Lelu, täältä haet? sanoi Jim.

— Tulin vain tänne katsomaan, näkyykö kokasta kaloja.

— Ei siellä mitään kaloja näy, sanoi Jim.

— Vai ei näy. Saanhan sitten katsella sinua, ollaanhan vanhoja

tuttavia Rose Fiddlerin ajoilta.

— Ollaan kyllä, pikku geisha. Mutta lennä pois alahangan puolitse;

tuolta tulee mrs. Fiddler.
 Asiahan oli selvä. "Ensikertalainen", joka ei enää ollutkaan
ensikertalainen, koska oli jo toisen laivan jungmannina, oli kaunis,
rohkea merimiehen alku, vaikkakin vielä näytti nappulalta
katsellessaan sinisillä, rehellisillä ja lapsellisilla silmillään maailmaa.
Pikku geisha, joksi häntä joskus sanottiin, ei ollut japanilaisessa
merkityksessä mikään geishan alku. Hän oli kaunis, vartaloltaan
pienenläntä nuori nainen… Ei hän oikeauskoisen japanilaisen
samuraimiehen silmissä ollut kaunotar, koska ei ollut
"puhdasverinen". Isä oli englantilainen herra ja äiti japanitar —
geisha.

Teresiaa vaivasi liian hyvä muisti. Kapteeni tosin toivoi ja

melkeinpä uskoikin tytön vähitellen kadottavan tämän kykynsä,
mutta perästä kuuluu. Kapteeni oli pyytänyt Chimbiä käyttämään
ihmeellistä valtaansa Teresiaan siihen suuntaan, että tämä unohtaisi
tuon paronipojan. Mrs. Fiddler taas oli toivossa saada Kap Hornin
kohdalla tavata miehensä. Entä Chimb!? Kuinkahan hänen laitansa
oli? Hän, jonka sydän oli niin hellä, että hän lähimmäisensä edestä
olisi antanut sielunsa ja ruumiinsa, oli sydämetön. Yksi meistä
neljästä oli ollut siinä toivossa, että hän saa Chimbin sydämen: se oli
tuo rikas, kunnon mies ja ensiluokan gentlemanni, Charles Clarck.
Hän oli kerran, kauan asiaa mietittyään, uskaltanut sanoa Chimbille:

— Saanko kätenne, kun tulemme Englantiin?

— Saatte sen heti puristettavaksenne, mutta ei sen kauemmaksi.

Charles ymmärsi nyt kerta kaikkiaan, ettei teräs pysty timanttiin.

Ilmat ovat pitkät ajat olleet kauniita. Tyytyväisyys loistaa kaikkien

silmistä. Naisetkin hengittävät myötätuulta. Chimb on terve sekä
sielultaan että ruumiiltaan. Hän loistaa kuin kultamalja kiilloitettujen
kuparikasarien keskellä.

Kaloista ei ole puutetta. Lentokaloja emme ole maistaneet sitten

Huanillasin. Bonitoja on ruvennut näkymään viime päivinä, ja on
niitä joitakuita jo saatukin, mutta vain maistiaisiksi. Maistinpalat on
tietysti annettu naisille. Nämä kalat, joita leikillä sanotaan porsaiksi,
koska ne ovat pyöreitä ja lihavia, ovat erinomaisen kauniita. Ne ovat
jalan, parin pituisia ja hyvin arkoja. Minkäänlaiseen uistimeen ne
eivät tartu, vaan niitä ongitaan istuen halkaisijapuomin päässä,
valkoinen kangastilkku syöttinä.

Jim Peg istuu usein, kun hänellä on vapaavahti, mainitussa

paikassa, säkki sidottuna puomiin, ja koettaa narrata bonitoja
onkeensa. Nämä tarttuvatkin helposti, mutta vain toinen puoli joutuu
säkkiin, toinen tempoo itsensä irti. Lelu seisoo kokkaäyräällä Pegin
onkiessa. Kalat hän vie naisille. Chimb ei pane paljoakaan arvoa
kalaruoalle. Eihän Andeilla kaloja pyydystetä eikä syödä! Pyöriäisiä
voisimme pyytää minkä verran tahansa, mutta harppuunin
käyttäminen on tässä laivassa kielletty.

Olemme sivuuttaneet Juan Fernandez-saaret. Ne jäävät kauaksi

väylästä, joka kulkee Chilen rannikon ja mainittujen saanen
keskivälitse. On vielä pitkä matka Kap Horniin. Olemme vielä
lämpöisessä vyöhykkeessä. Saimme sentään tänään muistutuksen
siitä, että Kap Horn lähenee meitä tai oikeastaan me sitä. Ehkäpä se
oli Kap Hornista sarvenpäästä — lähetetty tervehdys, joka merkitsi:
Pitäkää kiirettä!

— Jo liikkuu valaita. Kuuletko, West! sanoi Fred, kun seisoin

vieressä hänen ollessaan peräsimessä vähää ennen kello kahta yöllä.
 — En kuule mitään, sanoin. Kului vähän aikaa.

— Kuuletko nyt?

— Kuulen. Kaukaa kuului tuulen tuoma hiljainen puhallus. Sitten

kuului samanlaisia puhalluksia joka haaralta, ja viimein ylähangan
puolelta laivan takaa kova, pitkä puhallus. Olimme joutuneet
valasparveen. Nyt oli kello kaksi.

— Lyö, Fred, neljä lasia, että kuuluu, niin saamme nähdä, onko
noilla hyvät korvat. Fred teki työtä käskettyä. Ainakin Chimb kuuli
lyönnit ja tuli kannelle. Kokkapuolelta kaikui myöskin tavallista
kovemmat vastauslyönnit.

— Ei ole mitään hätää, koetettiin vain säikäyttää noita valaskaloja

tieltämme pois, sanoi Fred.

Vähitellen kokoontuivat kaikki kannelle kuulemaan ja katsomaan,

mitä oli tekeillä. Tunnin ajan valaskalat pyörivät ympärillämme.
Puhalluksia kuului läheltä ja kaukaa. Sitten hävisivät kaikki
merijättiläiset yht'aikaa. Kun kello kahdeksan aamulla otin vastaan
vahdinpidon, sanoi ensimmäinen upseeri, Bob Rogers:

— Katsokaa, mr. West! ja viittasi kädellään.

Ylähangan puolella puolen virstan matkan päässä valaat näkyivät

kulkevan jonossa samaan suuntaan kuin mekin. On lyöty seitsemän
lasia; väliin tehdään niin, kun kello on puoli kaksitoista päivällä ja
päällystöön kuuluvat henkilöt ovat eri hommissa laivassa, jotta nämä
tietävät kokoontua ottamaan auringon kulminaatiota. Kaikki paitsi
rouva Fiddler ovat kannella katselemassa valaskalojen leikkiä. Nämä,
joita on kuusi tai kahdeksan kappaletta, antavat näytäntöjä, joita
harvoin saa nähdä. Ne ajavat takaa toisiaan, pyörien laivan ympäri,
väliin hyvin lähellä. Ne sukeltavat syvyyteen, jossa viipyvät kauan.
Nostettuaan sitten suuren päänsä veden pinnan yläpuolelle ne
puhaltavat vesisuihkun. Joskus ne loikkaavat vedestä niin korkealle,
että koko niiden ruho tulee näkyviin. Nämä ovat kaskelotteja,
(Phyceter macrocephalus), maailman pisimpiä nisäkkäitä, joita elää
kaikissa valtamerissä paitsi Pohjois-Jäämeressä. Eniten niitä
kuitenkin tavataan Tyynessä valtameressä ja Etelä-Jäämeressä.
XV.

Olemme tänään leikanneet viidennenkymmenennen leveyspiirin.

Lähenemme pelättyä Kap Hornia. Chilen riuttainen rannikko
häämöittää idästä. Tämä pitkä rannikko, joka melkein koko matkan
on ollut saaretonta ja siis tarjonnut maalta katsojalle eheän
merinäköalan, on tästä lähin Kap Horniin saakka täynnä saaria.
Ilmakin tuntuu kolealta. Mutta täällähän on talvi. Olemme kesäkuun
puolivälissä. Jos kaikki käy kuten pitäisi, olisimme kesäpäivän
seisauksen eli kesäkuun 21-22 päivän vaiheilla Kap Hornin kohdalla,
viidennelläkymmenelläkuudennella eteläisellä leveyspiirillä. On jo
ruvennut näkymään Kap Hornin albatrosseja ja kapkyyhkysiä. Näistä
vesilinnuistahan kaikki ovat kuulleet puhuttavan, jos kohta harvat
ovat niitä nähneet. Albatrossi, joka kuuluu Pygopodes-lahkoon,
seisoo pystyssä kuin ihminen ja ulottuu miestä rintaan asti.
Kapkyyhkynen (Cap pigeon) on tavallisen kyyhkysen näköinen ja
kokoinen vesilintu.

Tuuli puhaltaa lännestä, ja laiva kallistelee tuntuvasti. On

paljonlaisesti purjeita päällä: pramipurjeet, paitsi perimmäinen, ovat
vielä ylhäällä. Öinen aika kun on, ottaisin ne pois, jos olisin yksin
ylähanganvahdin herra. Mutta kapteeni on itse kannella, joten se on
hän, joka määrää. Kävelen ympäri laivan kantta ja katselen, onko
kaikki kunnossa. Koettelen, luistavatko pramiraakojen laskuköydet.
Asetan miehen jokaisen laskuköyden luo, ja sitä paitsi yhden
peräkannen läheisyyteen, olemaan valmiina auttamaan ruorimiestä,
jos sattuisi tarvitsemaan. Tarkastaessani merkkilyhtyjä, huomaan
toisen niistä palavan huonosti. Laivassa täytyy aina olla myöskin
varalyhtyjä.

Kun tulin kompassihuoneen luo, seisoi siellä kapteeni. Hän kuului

antavan ruorimiehelle määräyksen pitää vähän ylemmäs tuuleen.
Kuului neljä lasia — kello oli kaksi.

— Hyvää yötä, mr. West! Minä menen nukkumaan.

Meillä on hyvänlainen vauhti. On koetettava päästä ympäri Hornin

ennen kesäpäivän seisausta. Silloin läntinen puhaltaa kovimmin.

— Älkää olko pelkuri; tarkoitan, älkää ottako pois pramipurjeita,

kyllä Columbian runko, taklaasi ja purjeet kestävät.

— Hyvää yötä, kapteeni!

Kapteenin mentyä alas mittasin laivan vauhdin: kymmenen

solmuväliä. Tämä vauhti näin kovassa aallokossa runtelee liian paljon
syväänlastattua laivaa, sen runkoa ja taklaasia.

Otin pois ensin etupramin ja puoli tuntia sen jälkeen keskipramin.

Sitten muutin kurssin ylemmäs tuuleen, niin ylös kuin tuulen suunta,
täysi läntinen, salli. Pelkäsin Chilen riuttarannikkoa. Jos tuuli kiihtyy
myrskyksi, voimme vähitellen ajautua maalle. Mitähän varten se
kapteeni ei ollut laskenut enemmän länttä kohden, ajattelin.
Seisoessani ruorimiehen vieressä tunsin, että joku laski kätensä
olkapäälleni.
 — Minua niin peloittaa! sanoi Chimb ja veti minua alamäkeä
kajuutan nurkan taakse.

— Mitä pelkäätte? kysyin.

— Rouva Fiddler istuu hytissään juhlapuvussaan ja lupaa vetää

Lelun ja minut laidan luo ja sitten…

En tahtonut puhaltaa pilliin ja säikäyttää nukkujia, vaan menin

keskikannelle puhuttelemaan yhtä miehistä. Ruorimiehelle sanoin: —
Jos näet rouva Fiddlerin tulevan kannelle, niin hälytä heti kellolla.

Pitäen Chimbiä kädestä menin John Stonefieldin luo.

— Mene rouva Fiddlerin hyttiin ja katso, ettei hän eikä Lelukaan

pääse kannelle, sanoin.

Kuuden lasin, kello kolmen, jälkeen hälytin vapaavahdin kannelle

ja reivasin märssipurjeet.

— Olkoon menneeksi, mutta kyllä minun mielestäni vielä olisimme

voineet kantaa enemmän purjeita, sanoi kapteeni. Ei ollut varaa
pitää miestä rouva Fiddlerin vartijana. Kapteenin tytär ja Chimb
vartioivat yhdessä hullua raukkaa. Lelusta oli myös apua; hänellä ei
ollut halua hypätä mereen. Ei mennyt ylähanganvahti kahdeksan
lasin jälkeen nukkumaan. Arvasimme, ettei siitä unesta tulisi
pitkällistä. Heti kello neljän jälkeen rupesi mr. Rogers vähentämään
purjeita, ja kahdeksaan mennessä oli päällä vain alamärssipurjeet ja
pari alimmaista taakipurjetta, nekin reivattuina. Laiva ei nyt enää
kulkenut päämäärää kohti, ja vielä vähemmin sitä kohti, mihin sen
kokka viittasi. Se kulki alahangan loorinki edellä Chilen
rannikkoriuttaa kohti. Ei voinut pitää niin paljon purjeita, että se olisi
kulkenut eteenpäin sen verran vain, että se tottelisi peräsintä. Kaksi
miestä seisoi peränpidossa, ja heillä oli täysi tosi pitää pyörästä kiinni
siten, ettei se päässyt varastamaan. Luulimme voivamme todeta,
että guanolasti ruumassa oli siirtynyt vähän alahankaan, koska laiva
oli mielestämme liian paljon kallellaan. Päätimme kääntää laivan
toiselle keulalaidalle. Se ei ollut helppo tehtävä! Eihän tämä temppu
voinut tapahtua, kuten tavallisesti, läpi vastatuulen. Laivan oli
käännyttävä kuten lehmän, takapuolitse. Laiva teki siis
lehmänkäännöksen ja makasi nyt kallellaan. Kapteeni ja Rogers
toivoivat, lapsellista kyllä, että lasti nyt valuisi hän takaisin, joten
laiva joutuisi tasapainoon.

— Kääntymisestä keulalaidalle on se etu, että se ehkä vähän estää

vauhtia, jolla lähenemme rannikkoa, mutta jos niin on, kuten
luulette, että lasti tällä keulalaidalla menee paikoilleen, niin olemme
hukassa. Silloinhan emme tiedä, milloin guano näkee hyväksi
muuttaa paikkaansa puolelta toiselle, sanoin.

Tämä lehmänkäännös oli toisaalta epäedullinen, sillä siihen meni

lähes puoli tuntia, ja sen ajan laiva kulki suoraa päätä rannikkoa
kohti.

— Meidän olisi ajoissa pitänyt suunnata enemmän länteen,

huomaan sen nyt. Mutta tahdoin kulkea suorinta tietä, sanoi
kapteeni.
XVI.

Myrsky on riehunut jo viisi päivää. Olemme syrjinpäin kulkeneet

hyvän matkaa etelään, jonne meidän on päästäväkin, mutta olemme
peloittavan lähellä riuttarannikkoa. Ainoa pelastuksemme on lisätä
purjeita, kävi sitten miten kävi. Ensiksi on vaikeata saada ylös
purjeita tämmöisessä ilmassa. Jos vielä köydet ja taklaasikin
kestäisivät, on hyvin luultavaa, että myrsky piiskaa purjeet rikki. Yksi
ainoa paukahdus, ja purje on kahtena kappaleena! Jos ajaudumme
Patagonian epävieraanvaraisille riutoille, niin on varma kuolema
edessä. Olisi vielä vähän elämisen toivoa, jos laiva, vaikkapa
pirstaleina, riehuvien aaltojen paiskaamana, ajautuisi mannermaan
rannalle. Mutta mantere ei voi ottaa meitä vastaan, koska riuttaiset,
asumattomat saaret reunustavat sitä. Ne meistä, jotka mahdollisesti
pääsisivät tämmöiselle saarelle elävänä, kuolisivat nälkään ja viluun.
Kukapa tietää, vaikka näillä saarilla oleskelisi peshereitä, joita
pidetään maailman villeimpinä ihmisinä ja ihmissyöjinä. Varjelkoon
jumala niistä! Kuinkahan lienee naisten laita? Ei ole aikaa ruveta
heitä hoitamaan. Ainoa, mitä voimme tehdä, on katsoa, etteivät
pääse pujahtamaan kannelle.

Tukala purjeiden nosto on nyt suoritettu. Columbia kyntää ja tonkii

merta kuin vihainen karju. Suojan puolella ovat mastot ja tangot
käyristyneet, ja vantit ja partuunit heiluvat löysinä, mutta tuulipuolen
vantit ja partuunit ovat jännitetyt kuin viulunkielet. Kannella on
melkein mahdotonta olla, sillä meri syöksyy tuulenpuolisen
kokkaäyrään yli ja huuhtoo puhtaaksi kaikki, mitä on irtonaista.
Tähystäjä istuu etumaston märssyssä kiinni köyttäytyneenä, sillä
sinne asti sylkäisee raivostunut meri. Laivan kallistuessa ja siirtyneen
guanon vielä lisätessä tätä kallistumista on märssyssä istuva mies
joskus lähellä aallonhuippua. On päiväinen aika, joten ei tavallisissa
oloissa tarvittaisi tähystäjää. Mutta tällaisissa olosuhteissa tähystäjä
on tarpeen, sillä hän näkee märssystä vastaan tulevat laivat, joita
kannelta en voi havaita suurten aaltojen vuoksi. Sitä paitsi tähystäjä
näkee, mitä omassa laivassa tapahtuu, ja voi viittomalla antaa
merkkejä. Ruorissa seisoo kaksi miestä kiinni köytettyinä, sillä meri
huuhtoo kaikki paikat puhtaiksi. Olen katsellut röstipultteja, joihin
vantit ja partuunit on kiinnitetty. Röstipenkit, joissa mainitut pultit
ovat, sijaitsevat laivan sivuilla jonkin matkaa skantäkkilistan
alapuolella. Katsellessani mainittuja pultteja, ajattelin itsekseni, että
jos nuo pultit pettävät, on koko masto ja siihen kuuluvat laitteet
nurin. Puusta rakennetuissa laivoissa niihin kyllä voi luottaa, sillä ne
kulkevat paksujen, sisäpuolella olevien pantereiden läpi. Mutta toista
on rautalaivoissa, kuten Columbiassa. Jos rautalaivan rostit pettävät,
irtaantuu koko levy, ja laivan sivuun tulee ammottava haava, josta
laivan kallistellessa meri pääsee sisään.

Tuli ilta. Ei ollut meillä paljon toivoa. Laivamme kyllä kulki

eteenpäin, tosin alahangan sivu hieman edellä. Joutuisimmeko jo
ensi yönä riuttojen uhriksi, vai tapahtuisiko se vasta huomisaamuna
päivänvalossa? Tietysti ei kukaan saanut mennä nukkumaan, eikä
siihen kellään ollut haluakaan. Menin alas naisten "kurjuuteen". Muut
paitsi Chimb näyttivät kuolleilta. Mutta Chimb oli ihan terve, ainakin
meri taudista.
 — Onko noissa henkeä? kysyin.

— Kyllä niissä on henki vielä, mutta ehkä ennättävät kuolla, ennen

kuin perikato tulee; onnelliset ihmiset! Nousen nyt kannelle. Tahdon
katsoa kuolemaa silmästä silmään. Ei minua laisinkaan peloita,
päinvastoin. Ensin olin vähän kiukkuisella tuulella. Luulin, että Suuri
Henki kostaa; luulin myös että minä olen Joonas, jonka tähden te
kaikki saatte kärsiä. Mutta nyt olen muuttanut mieleni tykkänään.
Ainoa, mitä minulla on sanottava, on, ettei kukaan saa koettaa
auttaa minua, sanoi Chimb.

Minulla ei ollut lohdutuksen sanaa Chimbille lähtiessäni

surkeudesta.

Kello on kymmenen; lasia ei ole lyöty pariin vuorokauteen.

Merkkilyhdyt eivät ole valaisseet, koska niitä ei pääse panemaan
paikoilleen, eivätkä ne palaisikaan, vaikka ne paikoilleen saisikin.
Mack Henderson on ruorissa ja hänellä on apumiehenä Jim Peg.
Chimb ja minä, molemmat kiinni köytettyinä, seisomme
kompassihuoneen luona.

— Pidä, Mack, niin ylös tuuleen kuin voit!

— All right! sanoi Mack.

— Älä toki niin ylös, että purjeet rupeavat elämään, sanoin

Mackille, katsottuani kompassia.

— Kyllä niissä on tuulta, sanoi Mack.

Jonkin ajan perästä alkaa laiva nostaa kokkaa korkeammalle ja

painaa perää tavallista syvempään. Mitäs tuo merkitsee, sanon
itsekseni. Eiväthän purjeet elä, ja kuitenkin on laivan kokka täydessä
vasta-aallokossa. Katselen taas kompassia, sanomatta mitään
Mackille. Eikä hänkään sano mitään, vaikka olisi paljon puhumista.
Kompassin viiva on taas kohonnut taulun asteisiin nähden. Tuuli on
kääntynyt pohjoisemmaksi. Katsomme toisiamme silmiin, Mack ja
minä, mutta ei kumpikaan lausu sanaakaan. Chimb puristaa kättäni
ja sanoo:

— Jokohan loppu on lähellä?

— Päinvastoin! Tuuli kääntyy myötäisemmäksi. Chimb ristii kätensä

ja kiittää jumalaa.

— Kuinka korkealle saan nousta? kysyy Mack.

— Täyteen lounaiseen, vastaan.

Mack ja Jimmy vetävät suunsa hymyyn. Lähden sitten kajuuttaan

ilmoittamaan ilosanomaa kapteenille ja Bob Rogersille.

— Panin suunnan täyteen lounaaseen, sanon näille, jotka

paraillaan pakkaavat kamssujaan ja laittautuvat valmiiksi ottamaan
perikatoa vastaan…

Olemme juuri Kap Hornin kohdalla. Jos vetäisi suoran viivan etelää
kohti Hermite-nimisestä korkeasta kalliosaaresta, joka muodostaa
Kap Hornin saariryhmän eteläisimmän kärjen, kohtaisi tämä suora
viiva Columbian kyljen. Länsituuli, joka vaaran uhatessa oli kääntynyt
luoteiseksi, ja siten pelastanut meidät joutumasta pampas-rannikon
riutoille, on taas totinen läntinen. Se vie meitä myötätuulessa,
lumimyrskyn riehuessa, vinhasti itää kohti. Kun laiva, oli se sitten
höyry- tai purjealus, kulkee suorassa myötätuulessa, kallistelee se
lakkaamatta sivulta toiselle. Tavallisesti silloin pidetään purjeita
päällä, usein enemmän kuin laivan ja taklaasin vahvuus oikeastaan
sallisi. Koetetaan päästä takaa hyökkäävän aallon tieltä pois, jottei se
tulisi sisään perän puolitse. Columbialla ei tällä kertaa ollut aikaa
kallistella. Aalto tuli sisään vuoron perään sivuilta, väliin
molemmiltakin sivuilta yhdellä kertaa. Laivan laidassa olevat
myrskyportit oli pidettävä auki, jotteivät aallot jäisi kannelle. Perää
pitäessä oli ruorimiehen huolehdittava, ettei koskaan antaisi paljon
ruoria. Laivan tuli tämmöisessä myrskyssä kulkea suoraan tuulen ja
aallon suuntaan.

Ei koko maapallolla ole sellaista myrskyaluetta, eikä missään nouse

niin ankaroita aaltoja kuin Kap Hornin luona. Jos laiva pääsee
varastamaan tuulen ja aallon suunnasta, kääntäen sivunsa aallokolle
ja samalla tuulta vasten, on se useimmiten tuhon oma.

Maapallon tällä puolen oli keskitalvi. Oli juhannuspäivä, josta

luulimme tulevan viimeisen päivämme. Mutta kaikkivaltias jumala ja
Suuri Henki olivat mukanamme. Kello oli kaksitoista päivällä ja mr.
Rogers hoiti peräsintä. Koska vain kaikkein paraimmille peränpitäjille
uskottiin peräsin kovassa myrskyssä, pitivät päällysmiehetkin joskus
perää. Mr. Rogers oli voimaansa luottaen vähäksi aikaa laskenut pois
apumiehensä. Kun laiva rupesi ryöstämään, eivät mr. Rogersin
voimat riittäneetkään. Äkkiä oli laiva kääntänyt sivunsa vasten tuulta
ja aallokkoa ja kaatui niin kallelleen, että toinen puoli kantta oli
veden alla. Tässä asennossa se oli sitten lähes puoli tuntia.
Pramitangot raakoineen, partuuneineen ja staageineen tulivat alas ja
viskaantuivat mereen. Jos joku olisi ollut kohdalla, olisi hän
kohdannut kuolemansa.

Ensimmäinen tehtävä oli saada hakatuksi poikki ne taklaasinosat,

jotka olivat kannella ja meressä. Mutta kuinka päästä hakkaamaan?
Kansihan oli siksi pystyssä, ettei tuulen puolelle päässyt muu kuin
kissa. Kansi oli ihan täynnä rojua — taklaasia, tankoja ja niiden päitä
sekä köysiä. Jolleivät pramitangot raakoineen ja muine rojuineen
olisi tulleet alas, ja jollei guanoharja lastiruumassa olisi siirtynyt
alahangan puolelle ja siten estänyt harjua tykkänään kaatumasta,
olisi Columbia kääntänyt pohjansa ylöspäin.

Kun viimein, käytettyämme kaikkia mahdollisia, vieläpä

mahdottomiakin keinoja, oli saatu hakatuksi poikki kaikki roju, joka
piteli laivaa kallellaan, saatiin se nousemaan entiseen asentoonsa. Se
kulki nyt tuulen ja aallon ajamana syrjittäin. Ei ollut purjeita.
Lumipyry vain vinkui siinä taklaasissa, mitä vielä oli jäljellä, ja meri
piti kantta asuntonaan.

Olimme kaikki väsyneitä ja märkiä niin kuin albatrossit ja

kapkyyhkyset, jotka leijailivat hyvin lähellä laivaa, katsellen itselleen
mukavaa yömajaa Columbiassa. Ensi työksemme laitoimme
vahvoista köysistä kulkuväyliä kannelle. Oli vaaranalaista kulkea,
jollei ollut mihin tarttua, kun liikkui kannella. Laivan timperi näkyi
peilaavan pumppuja. Hän ilmoitti, että laiva oli melkein tyhjä
vedestä.

Kuinkahan oli naisten laita? Kapteeni tuli kajuutasta ja ilmoitti

heidän seisovan vyötäisiään myöten vedessä. Laivan ollessa puoleksi
nurin oli vesi mennyt ovesta sisään. He olivat olleet siinä luulossa,
että laiva oli uppoamaisillaan. Chimb tuli ensimmäiseksi kannelle. Me
neljä olimme lähettyvillä ja huusimme hänelle yhteen ääneen
osapuilleen näin:

— Rakas signoritamme, kuinka on laitanne? Vastaus kuului:

 — Omat rakkaat poikani, minua vähän palelee ja minun on kova
nälkä. Jos ei uppoamisesta tällä kertaa tule mitään, on meidän
saatava jotakin syötävää.

Olemme kaikki Columbian matkaajat kompassihuoneen solan

luona. Tämä paikka on turvallisin. Laivan suurin, kuumalla kahvilla
täytetty kattila ja sen vieressä Chimb, on piirin keskipiste. Kahvin,
laivakorppujen ja australialaisen säilykelampaanlihan virkistäminä
katselemme silmästä silmään sitä, mikä nyt seuraa. Alkaa hämärtää.
Merenkäynti ja lumipyry asettuu. Pilvet häviävät, ja tähtiä alkaa
näkyä. Muutos on tapahtunut huomaamattamme. Laivaa heiluttelee
valtava maininki. Mutta se ei merkitse koko maailmaa, kun ovat
poissa nuo korkeat, raskaat mastojen jatkot, pramitangot, raakapuut
ja ylin taklaasi. On taas asetettu merivahti ja laivan miehistö nukkuu
vuoroon. Käännelköön ja väännelköön laiva runkoaan niin paljon
kuin haluaa. Ei se nyt vähällä käännä pohjaansa ylöspäin. Laivan
ruoripyörä on köytetty lujasti kiinni, ettei peräsin pääse viskelemään
edestakaisin. Mitä sitten tehdään, kuinka päästään eteenpäin ja
mihin ensin joudutaan, se on huomispäivän huoli!

Maattuani lähes neljä tuntia kuninkaallisesti kojussani, märkänä ja

kylmästä väristen, herään huutoon: — Kaikki miehet kannelle! Laiva
on uppoamaisillaan!

Alahangan vahdin ollessa kannella oli ruvennut lastiruumasta

kuulumaan outoa kolinaa. Timperin päästyä muonakellarin kautta
lastiruumaan, huomasi hän, että guanon päällä oli lähes pari jalkaa
vettä. Guanovelli, joka loiski ruumassa, heitteli edestakaisin
varatankoja, lankkuja ja pölkkyjä, jotka olivat olleet köytetyt
guanolastin päälle. Kannella oli ensimmäinen tehtävämme ruveta
irroittamaan veneitä köytöksistään. Sen jälkeen mitattiin vesi
pumpuissa ja huomattiin, ettei laivan pohjassa ollut vettä. Lähteä
veneellä Kap Hornin seuduissa merelle oli melkein varma kuolema.
Siksi tarkistettiin päätöstä ennen kuin ruvettiin laskemaan veneitä
vesille. Syy siihen, että guanon päälle oli päässyt vettä, oli seuraava.
Eilen laivan sivun joutuessa vasten tuulta ja aallokkoa, olivat
perämaston vantit ja partuunit painostuksessa reväisseet irti
röstipulttien kiinnityslaatan. Laivan sivuun tuli täten puolentoista
sylen pituinen ja puolentoista jalan levyinen aukko. Se laski vettä
laivan sisään joka kerta aallon lyödessä siihen, mutta etenkin laivan
kallistuessa aukon puolelle. Jottei repeämästä tulisi vettä sisään,
laitettiin sen kohdalle riippumaan moninkertaisesta presenningistä
tehty peitto, jonka alalaidassa oli rautakisko. Tämä keino ehkäisi
jonkin verran veden tuloa. Peräluukkua ei uskallettu avata, ennen
kuin oli nikkaroitu lankuista vahva, vedenpitävä, kahden ja puolen
kyynärän korkuinen arkku sen ympäri. Nyt nähtiin, miten guanovelli
heilahteli ruumassa.

Sitten pantiin donkey (höyrykone) käymään. Tämän avulla

mätettiin yöt ja päivät velliä mereen, siten että kaksi tynnyriä, joista
toinen pohja oli lyöty pois, lakkaamatta vuoroon nosti ruumasta
velliä mereen. Suuremmissa purjelaivoissahan on höyrypannu ja -
kone lastin purkamista varten. Purjeita saatiin pystyyn sen verran,
että viiden, kuuden solmuvälin vauhdilla päästiin kulkemaan.
Saavuimme viikon kuluttua Port Williamiin Falklannin itäsaaressa,
heitettyämme mereen neljännen osan lastista. Port William, joka
sijaitsee 51°41' eteläistä leveyttä, oli pieni vaatimaton satamapaikka.
Laivat käyttivät sitä pääasiallisesti pitkillä vaivalloisilla matkoilla
saamiensa vammojen korjaamispaikkana. Luonnollisesti silloin
otettiin laivaan vettä ja muonaa. Pohjois-Amerikan länsirannikolta
asti tuleville laivoille oli poikkeaminen Falklannin saarille välttämätön.
XVII.

Falklannin saaret kuuluvat Englannille. Port William oli luultavasti

näiden tärkein paikka siihen aikaan. Satamassa oli ankkurissa kaksi
valaanpyyntilaivaa, yksi englantilainen sotalaiva ja — vanha, hyvä
tuttumme Deutschland! Vaikka nämä saaret eivät ole erittäin
korkealla leveyspiirillä, on niiden talvi kovanlainen. Maa oli ohuen
lumen peitossa, ja oli muutamia pakkasasteita, kun saavuimme Port
Williamiin. Ankkuroimisen ja purjeiden käärimisen jälkeen oli ensi
työmme nousta maihin ostamaan kivihiiliä, jotka olivat loppuneet,
syystä että höyrykoneemme oli käynyt yötä päivää. Kajuutta ja
skanssi olivat jääkylmiä, vuorokauteen emme olleet saaneet keitettyä
ruokaa eikä kahvia. Sitten oli mentävä englantilaiseen sotalaivaan
pyytämään neuvoa ja avustusta Columbian korjausta varten. Olihan
Port Williamissa jonkinlainen korjauslaitos, jonka kruunu omisti,
mutta se auttoi luullakseni vielä Deutschlandia.

Hyvissä voimissa ja hyvällä tuulella oleva Chimb kertoi Teresian

menneen hyttiinsä itkemään nähtyään Deutschlandin täällä. Ensin oli
itku ollut iloitkua, mutta oli sitten muuttunut totiseksi itkuksi. Olihan
luultavaa, ettei paronipoika enää välittänyt hänestä. Rouva Fiddler oli
lukinnut kalleutensa kirstuunsa. Hän oli ollut huonolla tuulella siitä
saakka kun huomasi, ettei Columbian uppoamisesta tullut mitään.