562 lines
No EOL
44 KiB
HTML
562 lines
No EOL
44 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>1.3. Themes and Guiding Principles — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="4. System Architectures" href="Architectures.html" />
|
||
<link rel="prev" title="2. Systems and Models" href="SysAndModels.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="Themes.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="Themes.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/Themes.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="SysAndModels.html">1.2. Systems and Models</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="Architectures.html">1.4. System Architectures</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "Themes";ODSA.SETTINGS.MODULE_LONG_NAME = "Themes and Guiding Principles";ODSA.SETTINGS.MODULE_CHAPTER = "Introduction to Computer Systems"; ODSA.SETTINGS.BUILD_DATE = "2021-06-14 17:15:25"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="themes-and-guiding-principles">
|
||
<h1>1.3. Themes and Guiding Principles<a class="headerlink" href="Themes.html#themes-and-guiding-principles" title="Permalink to this headline">¶</a></h1>
|
||
<p>When describing systems and their behavior, there are three central themes that emerge. The first is
|
||
that <em>computer systems create a platform for applications</em>, acting as a foundation for advanced
|
||
work. Using that foundation effectively requires understanding that <em>systems have semiotics</em>, which
|
||
means that all communication – whether between system components or between the system and the user
|
||
– exist within a context that influences how messages are interpreted. Lastly, because system
|
||
designers cannot predict how the system will be used – particularly when the number of users
|
||
increases – <em>systems entail complexity</em>, leading to unintended properties that may be beneficial or
|
||
detrimental. The remainder of this book is devoted to addressing these themes, while identifying
|
||
guiding principles for designing and implementing systems correctly and efficiently.</p>
|
||
<div class="section" id="systems-as-foundations-of-computing">
|
||
<h2>1.3.1. Systems as Foundations of Computing<a class="headerlink" href="Themes.html#systems-as-foundations-of-computing" title="Permalink to this headline">¶</a></h2>
|
||
<p>Computer systems are not built to exist in isolation. Rather, computer systems are platforms
|
||
intended to create a foundation for advanced applications. As shown in
|
||
<a href="Themes.html#themessysapps">Figure 1.3.1</a>, applications rely on the OS to provide common services, such as access
|
||
to the file system or network. Some OS components, such as the scheduler, rely solely on the
|
||
hardware as a platform. Others rely on subsystems within the OS, such as the generic file
|
||
interface <a class="footnote-reference" href="Themes.html#f1" id="id1">[1]</a>. These subsystems, in turn, rely on the interfaces to hardware components, such as
|
||
storage devices, memory units, or network cards. In all cases, a higher-level software component is
|
||
relying on a reactive system that provides service upon request.</p>
|
||
<div class="figure mb-2 align-right" id="id5" style="width: 45%">
|
||
<span id="themessysapps"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.3.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Applications rely on OS services, built on top of other OS services and hardware" src="_images/CSF-Images.1.3.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.3.1: Applications rely on OS services, built on top of other OS services
|
||
and hardware</span></p>
|
||
</div>
|
||
<p>One key factor to consider when designing concurrent systems software is the <a class="reference internal" href="Glossary.html#term-scarcity-of-resources"><span class="xref std std-term">scarcity of resources</span></a>.
|
||
Individual computers have a limited number of CPU cores that can execute software at the same time.
|
||
Similarly, applications must share access to a finite amount of physical memory resources.
|
||
Consequently, systems software must explicitly manage and control access to shared resources, so as
|
||
to prevent applications from interfering with each other or corrupting each other’s work.</p>
|
||
<p>In order to manage the scarcity, system designers must address the inherent tradeoffs based on the
|
||
available resources. There are several common tradeoffs that should be considered. The <a class="reference internal" href="Glossary.html#term-space-time-tradeoff"><span class="xref std std-term">space/time tradeoff</span></a>
|
||
describes the phenomenon that using more resources for a short period of time can lead to faster
|
||
execution. One example of this is the creation of a buffer for exchanging data. A small buffer would
|
||
lead to more messages send back and forth, leading to a larger total delay; a large buffer could
|
||
allow all data to be sent in a single message, but that reduces the memory (space) available for
|
||
other software running.</p>
|
||
<p>A second tradeoff to consider is the <a class="reference internal" href="Glossary.html#term-interface-abstraction"><span class="xref std std-term">interface abstraction</span></a>. Consider the system design in
|
||
<a href="Themes.html#themessysapps">Figure 1.3.1</a>, described previously. In this OS design, the network interface,
|
||
file system, and memory management all rely on a common interface abstraction that everything is a
|
||
file. That is, all of these services should be treated as a sequence of bytes, with an integer file
|
||
descriptor used to identify the data stream. This approach allows all of these subsystems to use
|
||
common functions <code class="docutils literal notranslate"><span class="pre">read()</span></code> and <code class="docutils literal notranslate"><span class="pre">write()</span></code> to interact with the system. However, this generic
|
||
interface obscures some key differences between network communications and data stored on a hard
|
||
drive. For instance, once a message is retrieved from a network card, the message is removed from
|
||
the network card’s internal memory, as if it has been destroyed; that is, an application cannot rely
|
||
on the network card to store the message persistently for reference whenever it is needed. On the
|
||
other hand, that is exactly the service that files on a hard drive provide. Consequently,
|
||
abstracting away these differences provides a common interface, but eliminates the possibility of
|
||
optimizing the interface based on the specific hardware component.</p>
|
||
<p>Another tradeoff that commonly arises involves <a class="reference internal" href="Glossary.html#term-security-vs-usability"><span class="xref std std-term">security vs. usability</span></a>. A hard drive can be
|
||
made perfectly secure by smashing it with a hammer; no malicious adversary would then be able to
|
||
steal your data, but you would no longer be able to use it either. In a significantly less extreme
|
||
example, network messages might employ security techniques to ensure all of the data is transferred
|
||
and only the intended recipient reads it. The downside is that this level of security may be
|
||
unnecessary and, even worse, the verification procedures involved are too slow for the application to use.</p>
|
||
<p>All computer system designs must entail compromises. The scarcity of resources makes it necessary to
|
||
balance the factors that influence these tradeoffs in order to support higher-level applications
|
||
effectively. System architects – especially those building systems intended for general-purpose use
|
||
– must predict what applications will be deployed and how best to balance these factors for the
|
||
specific context of those applications.</p>
|
||
</div>
|
||
<div class="section" id="systems-and-complexity">
|
||
<h2>1.3.2. Systems and Complexity<a class="headerlink" href="Themes.html#systems-and-complexity" title="Permalink to this headline">¶</a></h2>
|
||
<p>Computer systems are <a class="reference internal" href="Glossary.html#term-complexity"><span class="xref std std-term">complex</span></a>. This does not simply mean that they are complicated, though
|
||
that is certainly the case. Taking a system design from specification to implementation requires
|
||
close attention to details that may not be immediately obvious. Changing the order of two lines of
|
||
code, using a different compiler option, or inadvertently freeing a pointer at the wrong time can
|
||
all lead to catastrophic system failures. These are examples of how implementing computer systems is
|
||
a complicated task that requires special care.</p>
|
||
<p>Complexity, on the other hand, means something more than just being complicated. Complexity implies
|
||
that the system exhibits <a class="reference internal" href="Glossary.html#term-emergent-property"><span class="xref std std-term">emergent properties</span></a> that are not intuitive or
|
||
obvious from the design. Interactions between entities in a system leads to unintended combinations
|
||
of behaviors and system configurations. One example of an such unanticipated behavior in an OS is
|
||
known as Bélády’s anomaly, which describes the unusual scenario where adding more memory resources
|
||
to a computer actually leads to slower performance. Other emergent properties arise when entities
|
||
compete for access to shared resources. In deadlock, two or more processes simultaneously block each
|
||
other’s access in a permanent and unresolvable stalemate; process A has something that process B
|
||
needs and vice versa, but neither will give up what they possess. In priority inversion, a
|
||
high-priority task may be prevented from running by a low-priority task.</p>
|
||
<p>Networked computers often experience attacks as emergent properties that exploit non-obvious
|
||
vulnerabilities. One example of such an attack is a syn flood, in which thousands or millions of
|
||
coordinated nodes send requests for service to the same server. As the server allocates resources to
|
||
process these requests, it quickly runs out of memory and crashes. Another example is a replay
|
||
attack on a security protocol. In a replay attack, a malicious adversary snoops on network traffic
|
||
and observes that a user was successfully logged in after sending a particular message; the
|
||
adversary does not actually know what the message says, but they send it anyway and are also granted
|
||
access.</p>
|
||
<p>In all of these cases, complexity is the result of unanticipated sequences of actions that lead to
|
||
new and unusual configurations. As a result, computer system designers must accept that
|
||
<strong>reliability is elusive</strong>. When a system is designed and implemented, the developers routinely
|
||
perform a number of tests to convince themselves that the system behavior is correct. However, these
|
||
testing procedures are inherently limited and cannot provide strong assurances. Given this
|
||
challenge, many systems are designed to use redundancy to overcome probabilistic errors.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="themeredundancy">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 1.3.1 </p><hr class="mt-1" />
|
||
<p>To illustrate how redundancy provides reliability, consider a system component that has a 1%
|
||
probability (p = 0.01) of failing within a particular time frame. Adding a second copy as a
|
||
back-up, decreases the probability of that component failing to 0.01% (p = 0.01 * 0.01 = 0.0001),
|
||
as an overall failure requires both copies to fail <em>at the same time</em>. Adding a third copy as
|
||
backup decreases the probability to 0.0001% (p = 0.01 * 0.01 * 0.01).</p>
|
||
</div>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="themeredtcp">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 1.3.2 </p><hr class="mt-1" />
|
||
<p>As another example of reliability through redundancy, consider the TCP network protocol. In TCP, a
|
||
device sends a <a class="reference internal" href="Glossary.html#term-segment"><span class="xref std std-term">segment</span></a> of information to another device, waiting for a response. If the
|
||
response does not arrive within a pre-designated time frame, TCP resends the message but increases
|
||
the waiting time limit. Note that increasing the wait time has the effect of reducing the
|
||
probability of failing to get the response back in time. For instance, maybe the first time limit
|
||
was 10 ms, but the response actually took 12 ms. For the second message, the time limit was
|
||
increased to 15 ms, so the 12 ms response time is acceptable. Sending redundant messages,
|
||
especially when the time limit for receiving a response is increased, improves the overall
|
||
reliability of the protocol.</p>
|
||
</div>
|
||
<p>Computer systems designers and developers must also accept that <strong>system complexity breeds
|
||
misunderstanding</strong>. In many cases, the root causes of an error or failure are hidden by the
|
||
complexity. Since errors and other emergent properties arise from unanticipated sequences of
|
||
actions, anyone trying to debug the system afterward might not have enough information to determine
|
||
what went wrong; the system simply may not have been logging the most relevant information to
|
||
reconstruct the cause. As an example, consider the following line of C code:</p>
|
||
<div class="highlight-c border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span><span class="n">printf</span> <span class="p">(</span><span class="s">"hello, %s"</span><span class="p">,</span> <span class="n">user</span><span class="p">);</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Assume that the system has crashed, and the developer is using this line as a hint for debugging.
|
||
After examining the output, the developer observes no mention of this line of code and concludes
|
||
that the error occurred before this point. Further investigation reveals that the <code class="docutils literal notranslate"><span class="pre">user</span></code> pointer
|
||
was initialized correctly, so this line of code did not cause the segmentation
|
||
fault.</p>
|
||
<p>Without closer investigation, it is possible that any of those claims were wrong. The <code class="docutils literal notranslate"><span class="pre">user</span></code>
|
||
variable may have been initialized correctly, but another part of the code may have corrupted the
|
||
pointer, making it null. Alternatively, the null-byte at the end of the string may have been
|
||
modified, converting the <code class="docutils literal notranslate"><span class="pre">user</span></code> string “Alice” to turn into “Alice&76as87d92f00d9f8…” If that
|
||
new string is long enough (before encountering another null-byte, the parameter would overflow the
|
||
stack in an internal library function.</p>
|
||
<p>Even worse for debugging, <em>this line may have been executed successfully without error</em>. Observe
|
||
that the printed string does not end with a <code class="docutils literal notranslate"><span class="pre">'\n'</span></code>. When this happens, <code class="docutils literal notranslate"><span class="pre">printf()</span></code> does not
|
||
necessarily cause the message to be printed immediately. Rather, the message gets placed into a
|
||
buffer for printing when the buffer gets flushed. If the program crashes before the buffer is
|
||
flushed, the message is simply lost. Consequently, when debugging complex systems, it is critically
|
||
important to use the correct tools; relying on print statements is no longer sufficient, as they may
|
||
cause you to look in the wrong place.</p>
|
||
</div>
|
||
<div class="section" id="the-semiotics-of-computer-systems">
|
||
<h2>1.3.3. The Semiotics of Computer Systems<a class="headerlink" href="Themes.html#the-semiotics-of-computer-systems" title="Permalink to this headline">¶</a></h2>
|
||
<p>The term <a class="reference internal" href="Glossary.html#term-semiotics"><span class="xref std std-term">semiotics</span></a> <a class="footnote-reference" href="Themes.html#f2" id="id2">[2]</a> describes the use and interpretation of symbols and signs. That
|
||
is, semiotics focuses on how communication should be interpreted based on the language used and the
|
||
context of the messages. Understanding the semiotics of a message involves considering the relevant
|
||
<a class="reference internal" href="Glossary.html#term-syntax"><span class="xref std std-term">syntax</span></a>, <a class="reference internal" href="Glossary.html#term-semantics"><span class="xref std std-term">semantics</span></a>, and <a class="reference internal" href="Glossary.html#term-pragmatics"><span class="xref std std-term">pragmatics</span></a>. The syntax defines to the rules that
|
||
control how symbols can be combined to create a message. The semantics define the meaning of the
|
||
individual symbols. The pragmatics characterize the relationship between the message and the entity
|
||
making sense of the message. The semiotics of computer systems can be explored along three
|
||
dimensions: machine-to-machine, machine-to-human, and machine-to-world.</p>
|
||
<p>The first dimension – and the most well understood – focuses on the communication between two
|
||
computer systems. That is, when two systems need to exchange information, what data structures,
|
||
communication protocols, and applications will be involved? In <em>Computer Systems: A Programmer’s
|
||
Perspective</em> <a class="reference internal" href="Bibliography.html#bryant2015" id="id3">[Bryant2015]</a>, Bryant and O’Hallaron capture this idea with the statement that <strong>information = bits +
|
||
context</strong>. That is, computers store data in binary form (bits) that conveys no meaning without
|
||
applying the relevant context. The semiotics view of systems expands Bryant and O’Hallaron’s
|
||
statement by distinguishing the semantics (what the symbols mean) from the pragmatics (what the
|
||
computer does in response).</p>
|
||
<div class="figure mb-2 align-right" id="id6" style="width: 35%">
|
||
<span id="themesbits"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.4.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The same sequence of 8 bits can have several possible semantics" src="_images/CSF-Images.1.4.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.3.4: The same sequence of 8 bits can have several possible semantics</span></p>
|
||
</div>
|
||
<p>The syntax dimension of semiotics imposes a structure on the bits; a simple example of this
|
||
structure is the fact that binary data is typically read as bytes – groups of eight bits. Consider
|
||
the bits shown in <a href="Themes.html#themesbits">Figure 1.3.4</a>. The semantics of <em>byte</em> indicate that the
|
||
least-significant bit is placed on the right, yielding the unsigned integer value 174 or the signed
|
||
integer -82. Applying the semantics of characters would yield the value ‘®’. An <em>octet</em> is another
|
||
numeric semantic interpretation group of eight bits, but with the least-significant bit on the left;
|
||
this octet has the decimal value 117. The pragmatics of the context implies whether or not the
|
||
program in question can read that kind of file.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="themehexdump">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 1.3.3 </p><hr class="mt-1" />
|
||
<p>To make these terms more concrete within the context of computing, consider the outputs of calling
|
||
the <code class="docutils literal notranslate"><span class="pre">hexdump</span></code> command-line utility on two files (for the latter, only selected lines are shown):</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>$ hexdump -C data.xml
|
||
00000000 3c 6d 65 6e 75 3e 3c 6f 70 74 69 6f 6e 3e 4f 70 |<menu><option>Op|
|
||
00000010 65 6e 20 46 69 6c 65 3c 2f 6f 70 74 69 6f 6e 3e |en File</option>|
|
||
00000020 3c 2f 6d 65 6e 75 3e 0a |</menu>.|
|
||
00000028
|
||
$ hexdump -C data.mp3 | head -n 150 | tail -n 3
|
||
000024d0 03 11 00 3f 00 fe 9d 6f f4 d3 3e 8b a8 4c 23 8a |...?...o..>..L#.|
|
||
000024e0 e6 2b d9 8c 37 70 18 8a 23 45 6a 03 a2 bc 6e 11 |.+..7p..#Ej...n.|
|
||
000024f0 dd 60 31 99 50 4c 1e de 44 93 7b 38 b7 12 35 77 |.`1.PL..D.{8..5w|
|
||
</pre></div>
|
||
</div>
|
||
<p>Different programs will read and interpret these files in distinct ways, starting with the syntax.
|
||
The syntax declares how the file contents must be structured. If the program is expecting XML, it
|
||
would expect the human-readable text structure as shown in the first file. A program expecting XML
|
||
would not be able to interpret the latter file successfully. A media player program, on the other
|
||
hand, would know how to interpet the binary data structures of the second file.</p>
|
||
<p>The semantics of the system then define what the file contents mean. For instance, the XML data is
|
||
intended to indicate that a user should be shown a menu that allows a user to open a file; it is
|
||
unlikely that the creator of the file intended this XML code to express how much they liked a movie
|
||
they saw. The semantics of the symbol <code class="docutils literal notranslate"><span class="pre">"<menu>"</span></code> has an intended meaning that the message is
|
||
conveying. As for the pragmatics, consider what would happen if you opened the MP3 file in an audio
|
||
player as compared to a text editor. There is a relationship between the MP3 file (the message) and
|
||
the audio player (the entity interpreting the message) that does not exist between the MP3 file and
|
||
the text editor.</p>
|
||
</div>
|
||
<p>The second way to consider the semiotics of computer systems is to examine how computer systems and
|
||
humans interact. In applications programming, this dimension includes usability concerns. In the
|
||
systems realm, understanding the syntax and the semantics entails learning a variety of functions
|
||
that define the API for interacting with the OS and the hardware. Computer systems provide many
|
||
services that can be used to exchange information between applications and coordinate the intended
|
||
work. Much of this book is devoted to explaining and documenting these APIs and how to use them.</p>
|
||
<p>At the same time, it is vital to address the pragmatics of computer systems-to-human interactions,
|
||
as <strong>human cognition and automated computation differ</strong>. Some concepts, such as multitasking (“doing
|
||
multiple things at the same time”), mean different things to humans and to computer systems. To
|
||
illustrate this concept, consider the following two lines of C code:</p>
|
||
<div class="highlight-c border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span><span class="n">x</span> <span class="o">=</span> <span class="n">x</span> <span class="o">+</span> <span class="mi">1</span><span class="p">;</span> <span class="n">x</span> <span class="o">=</span> <span class="n">x</span> <span class="o">-</span> <span class="mi">1</span><span class="p">;</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Assuming the variable x had an initial value of 5, what would be the result of executing these two
|
||
lines of code “at the same time”? Our intuition is that these lines of code are not literally
|
||
executed at the same physical moment, as they contradict one another. Instead, “at the same time” to
|
||
us means “at approximately the same moment” rather than the literal interpretation. The next
|
||
question we could ask, then, would be what final value of x should be expected. It may come as a
|
||
surprise that, after executing both of these statements “at approximately the same moment”, x could
|
||
end up with three possible final values: 4, 5, or 6. Understanding and addressing the differences
|
||
between human cognition and computing requires acknowledging the pragmatics of machine-to-human interactions.</p>
|
||
<p>The third dimension, which is of particular interest (but not limited) to those who design and build
|
||
embedded systems, is the relationship between the computer and the physical world. An embedded
|
||
system is one in which computing is integrated into a larger system that is not obviously devoted to
|
||
computation; examples of embedded systems include robotics, non-autonomous (i.e., not self-driving)
|
||
automobiles, or entertainment systems. The key insight to this dimension of semiotics is that <strong>the
|
||
computer itself is a model</strong>. That is, anything that can be achieved with the computer can only ever
|
||
be a simplified approximation of the world.</p>
|
||
<p>Another way to describe this issue is to note that computing is built on a digital (or discrete)
|
||
simulation of a world that is inherently analog (or continuous) in nature. One simple illustration
|
||
of this fact is to consider floating-point representations of real numbers. There are more real
|
||
numbers between 0 and 1 than we can store by combining all of the computing resources in the entire
|
||
world. That is often not a problem, as 0.1999999999999999 is a close enough approximation of 0.2 for
|
||
practical uses. <a class="footnote-reference" href="Themes.html#f3" id="id4">[3]</a></p>
|
||
<p>This digital approximate of analog phenomena can be found in other aspects of computing. For
|
||
instance, the very notion of a bit 0 or 1 is created by denoting whether or not an electrical device
|
||
measures a voltage above or below a given threshold. Devices can also be placed into a high
|
||
impedance state, in which the value of a bit is neither 0 nor 1. Similarly, time is a continuous
|
||
physical phenomenon that is not measured identically. Many computers create a discrete approximation
|
||
of time by measuring the vibrations produced by a crystal subjected to an electric charge. If we
|
||
were to zoom in on the measurements, there would be slight variations that can neither be predicted
|
||
nor controlled.</p>
|
||
<p>This last factor – time – is the most relevant to the discussion in this book. Concurrent computer
|
||
systems are, by definition, focused on coordinating the execution of software that is intended to
|
||
perform multiple tasks at more or less the same time. To accomplish this goal, the system designer
|
||
must take steps to inject timing controls – synchronization – into the implementation. At the same
|
||
time, the designer must learn to recognize that there are limits to what can be accomplished
|
||
regarding time. As this book progresses, time will become a central theme, leading to some
|
||
well-established but counterintuitive results that the challenge of time makes certain goals – such
|
||
as getting concurrent systems to agree on what time it is – are impossible.</p>
|
||
<table class="docutils footnote" frame="void" id="f1" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="Themes.html#id1">[1]</a></td><td>Our perspective of the OS structure derives from the UNIX and Linux design, in which all
|
||
devices are files.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f2" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="Themes.html#id2">[2]</a></td><td>Semiotics are commonly studied in human-centered fields of study, such as sociology or
|
||
anthropology. However, approaching the study of computer systems from this perspective allows one
|
||
to examine nuanced features of this field that lead to mistakes and failures.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f3" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="Themes.html#id4">[3]</a></td><td>The choice of 0.2 was intentional here. The standard floating-point representation, IEEE
|
||
754 format, cannot represent the exact value 0.2, as it cannot be written as a finite summation of
|
||
powers of two.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<div
|
||
id="ThemesSumm"
|
||
class="embedContainer"
|
||
data-exer-name="ThemesSumm"
|
||
data-long-name="Themes and principles questions"
|
||
data-short-name="ThemesSumm"
|
||
data-frame-src="../../../Exercises/IntroConcSys/ThemesSumm.html?selfLoggingEnabled=false&localMode=true&module=Themes&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="550"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="ThemesSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="SysAndModels.html">1.2. Systems and Models</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="Architectures.html">1.4. System Architectures</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |