425 lines
No EOL
28 KiB
HTML
425 lines
No EOL
28 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>3.2. IPC Models — 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="3. Pipes and FIFOs" href="Pipes.html" />
|
||
<link rel="prev" title="1. Concurrency with IPC" href="IPCOverview.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="IPCModels.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="IPCModels.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/IPCModels.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="IPCOverview.html">3.1. Concurrency with IPC</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="Pipes.html">3.3. Pipes and FIFOs</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 = "IPCModels";ODSA.SETTINGS.MODULE_LONG_NAME = "IPC Models";ODSA.SETTINGS.MODULE_CHAPTER = "Concurrency with IPC"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 15:31:50"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="ipc-models">
|
||
<h1>3.2. IPC Models<a class="headerlink" href="IPCModels.html#ipc-models" title="Permalink to this headline">¶</a></h1>
|
||
<p>There are multiple ways that different forms of IPC can be classified. The first and most common
|
||
distinction is to separate techniques that adhere to a <a class="reference internal" href="Glossary.html#term-message-passing"><span class="xref std std-term">message passing</span></a> model from a
|
||
<a class="reference internal" href="Glossary.html#term-shared-memory"><span class="xref std std-term">shared memory</span></a> model. In message passing, whenever a piece of data is to be exchanged, the
|
||
process will invoke the kernel with a request to send the information to the target process. That
|
||
is, the user-mode process will copy the data into a buffer or other form of data structure, then
|
||
issue a <a class="reference internal" href="Glossary.html#term-system-call"><span class="xref std std-term">system call</span></a> to request the data be transferred. Once the kernel is invoked, it will
|
||
copy the transferred data first into its own memory. At some later point, the target process will
|
||
also issue a system call to retrieve the data. In short, message passing techniques require the
|
||
kernel become involved in every distinct exchange of data.</p>
|
||
<p>Shared memory techniques work fundamentally differently than message passing. In shared memory, the
|
||
processes initially set up a region of their virtual memory to use for the IPC. Once the region is
|
||
established within the process, the process issues a system call to request that the kernel make the
|
||
region shared. Other processes would do the same. After the initial system call to set up the shared
|
||
memory, the processes can read from and write to the region just as it would access non-shared data
|
||
on its own heap. That is, the process could write to the region by dereferencing a pointer to it.
|
||
This data then appears within the context of the other process automatically. There is no explicit
|
||
system call required to read the new data.</p>
|
||
<div class="section" id="advantages-and-disadvantages">
|
||
<h2>3.2.1. Advantages and Disadvantages<a class="headerlink" href="IPCModels.html#advantages-and-disadvantages" title="Permalink to this headline">¶</a></h2>
|
||
<p>Message passing and shared memory both have advantages and disadvantages relative to each other. One
|
||
key dimension for comparing their performance is the amount of time overhead required. In message
|
||
passing, every piece of data exchanged requires two system calls: one to read and one to write. In
|
||
addition, the transferred data must be copied twice: once into the kernel memory and once into the
|
||
receiving process. For a single message, this time penalty is insignificant and is unlikely to
|
||
affect the process’s performance. However, if the number of messages passed is extremely large, the
|
||
cumulative effect of this penalty may be significant.</p>
|
||
<p>In contrast, shared memory techniques only require a one-time performance penalty during the set-up
|
||
phase. Once the memory has been shared, there is no additional penalty, regardless of the amount of
|
||
data transferred. The trade-off is that the penalty for setting up shared memory is significant. The
|
||
kernel must perform several slow operations to link the shared region to all of the processes’
|
||
virtual memory spaces.</p>
|
||
<p>Overall, if the two processes will be exchanging a lot of data back and forth repeatedly, shared
|
||
memory performs very well. While the work to set up the shared memory is expensive, the aggregate
|
||
effect of the performance is reduced. However, if processes only need to exchange a single message
|
||
of a few bytes, shared memory would perform very poorly. Message passing techniques impose
|
||
significantly smaller overhead to set up a one-time data exchange.</p>
|
||
<p>Shared memory also has another disadvantage that message passing avoids, which is the problem of
|
||
<a class="reference internal" href="Glossary.html#term-synchronization"><span class="xref std std-term">synchronization</span></a>. If both processes try to write to the shared memory region at the same
|
||
time, the result would be unpredictable and could lead to errors in one or both processes.
|
||
Consequently, the accesses must be synchronized, meaning that the timing is carefully controlled.
|
||
Since all message passing exchanges go through the kernel, synchronization techniques are not necessary.</p>
|
||
<p>As an example of the synchronization problem, consider an example where the two processes are
|
||
keeping track of money in your bank account. One process writes a record for a \$100 purchase that
|
||
you made, while another records a \$100 deposit. If both are recorded correctly, your new balance
|
||
should be the same as when the processes started. However, if the account record is in shared memory
|
||
and the writes are not properly synchronized, the results may not be correct. Instead of your final
|
||
balance being exactly what you started with, you may end up with \$100 more or less than your
|
||
original balance. Either you or your bank would be very unhappy with this result. Synchronization is
|
||
a complex topic and we discuss it in its own chapter.</p>
|
||
</div>
|
||
<div class="section" id="an-ipc-taxonomy">
|
||
<h2>3.2.2. An IPC Taxonomy<a class="headerlink" href="IPCModels.html#an-ipc-taxonomy" title="Permalink to this headline">¶</a></h2>
|
||
<p>There are several different IPC techniques that can be used for a variety of different purposes. In
|
||
<cite>The Linux Programming Interface</cite> <a class="reference internal" href="Bibliography.html#kerrisk2010" id="id1">[Kerrisk2010]</a> , Kerrisk provides a taxonomy of UNIX IPC that is
|
||
useful for classifying these techniques along a number of different dimensions. These dimensions
|
||
include which model (shared memory or message passing), the primary intended purpose (data exchange
|
||
or synchronization), and the granularity of the communication (byte stream or structured messages).
|
||
We could also add a distinction between network-based or local to a single machine. <a class="reference external" href="IPCModels.html#tbl3-1">Table 3.1</a>
|
||
shows this taxonomy.</p>
|
||
<p>Before summarizing the taxonomy, we note that the term <em>shared memory</em> has two meanings in IPC that
|
||
can cause some confusion. As we described above, shared memory is a general model that refers to the
|
||
fact that the IPC occurs in a region of memory that is co-present within the multiple processes.
|
||
Shared memory also refers to a specific technique for creating these regions; this technique uses
|
||
library functions that begin with shm, such as <code class="docutils literal notranslate"><span class="pre">shmat()</span></code> or <code class="docutils literal notranslate"><span class="pre">shm_open()</span></code>. There are other shared
|
||
memory techniques that rely on other functions. As an example, memory-mapped files are a form of
|
||
shared memory that also copies all data into persistently stored files; data shared with <code class="docutils literal notranslate"><span class="pre">shm</span></code>
|
||
functions only exists in memory. To avoid this collision of terminology, we will use <code class="docutils literal notranslate"><span class="pre">shm()</span></code> when
|
||
referring to the specific techniques while reserving the term <em>shared memory</em> for the more general model.</p>
|
||
<center>
|
||
<div class="row">
|
||
<div class="col-md-12">
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center">Technique</th>
|
||
<th class="py-0 center">Model</th>
|
||
<th class="py-0 center">Purpose</th>
|
||
<th class="py-0 center">Granularity</th>
|
||
<th class="py-0 center">Network</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center">pipe/FIFO</td>
|
||
<td class="py-0 center">message passing</td>
|
||
<td class="py-0 center">data exchange</td>
|
||
<td class="py-0 center">byte stream</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">socket</td>
|
||
<td class="py-0 center">message passing</td>
|
||
<td class="py-0 center">data exchange</td>
|
||
<td class="py-0 center">either</td>
|
||
<td class="py-0 center">either</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">message queue</td>
|
||
<td class="py-0 center">message passing</td>
|
||
<td class="py-0 center">data exchange</td>
|
||
<td class="py-0 center">structured</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">shm()</td>
|
||
<td class="py-0 center">shared memory</td>
|
||
<td class="py-0 center">data exchange</td>
|
||
<td class="py-0 center">none</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">memory-mapped file</td>
|
||
<td class="py-0 center">shared memory</td>
|
||
<td class="py-0 center">data exchange</td>
|
||
<td class="py-0 center">none</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">signal</td>
|
||
<td class="py-0 center">message passing</td>
|
||
<td class="py-0 center">synchronization</td>
|
||
<td class="py-0 center">none</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">semaphore</td>
|
||
<td class="py-0 center">message passing</td>
|
||
<td class="py-0 center">synchronization</td>
|
||
<td class="py-0 center">none</td>
|
||
<td class="py-0 center">local</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 3.1: Classifying standard IPC techniques based on several characteristics
|
||
</p>
|
||
</center><p>Although <a class="reference internal" href="Glossary.html#term-signal"><span class="xref std std-term">signals</span></a> are covered in another chapter, we include them in this taxonomy
|
||
because they can be interpreted as a limited form of IPC. Signals do not include any data and they
|
||
are received asynchronously by the destination process. As such, they are very limited in the
|
||
information they are conveying; they simply alert another process of a particular type of
|
||
pre-defined event. However, this can be interpreted as a form of IPC.</p>
|
||
<p><a class="reference internal" href="Glossary.html#term-socket"><span class="xref std std-term">Sockets</span></a> are a flexible form of message passing IPC that can be used in multiple
|
||
ways. The most common way that sockets are used is to send data across a network connection. As
|
||
such, we will not consider sockets in this chapter and will explore their uses when discussing
|
||
networks.</p>
|
||
<div
|
||
id="IPCModelSumm"
|
||
class="embedContainer"
|
||
data-exer-name="IPCModelSumm"
|
||
data-long-name="IPC models questions"
|
||
data-short-name="IPCModelSumm"
|
||
data-frame-src="../../../Exercises/IPC/IPCModelSumm.html?selfLoggingEnabled=false&localMode=true&module=IPCModels&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="3"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="IPCModelSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="IPCOverview.html">3.1. Concurrency with IPC</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="Pipes.html">3.3. Pipes and FIFOs</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> |