-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathiotraits.html
More file actions
175 lines (165 loc) · 9.25 KB
/
iotraits.html
File metadata and controls
175 lines (165 loc) · 9.25 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />
<title>Brief discussion of input/output interface traits — Nothing special</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
<link rel="stylesheet" type="text/css" href="_static/classic.css" />
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
<script src="_static/doctools.js"></script>
<script src="_static/sphinx_highlight.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="copyright" title="Copyright" href="copyright.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="nav-item nav-item-0"><a href="index.html">Nothing special</a> »</li>
<li class="nav-item nav-item-this"><a href="">Brief discussion of input/output interface traits</a></li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="brief-discussion-of-input-output-interface-traits">
<h1>Brief discussion of input/output interface traits<a class="headerlink" href="#brief-discussion-of-input-output-interface-traits" title="Permalink to this heading">¶</a></h1>
<p>Despite the considerable number of different programing interfaces, which are
present in the popular and not so much operating systems, there are,
essentially, less than two real ways to perform input/output operations. It
seems worthwhile to analyse these methods briefly, as a useful exercise and a
reminder.</p>
<p>First, we need to establish, what does I/O operation means. In its simplest
form, I/O corresponds to retrieval of the information which can not be obtained
through local memory access, or, in other words, fetched by short enough CPU
command sequence on behalf of currently executing program. Of course, really
useful information almost never can be found locally (this is, undoubtedly, one
of the greatest creation mysteries), so any non-trivial program devotes major
parts of its code and run time to the matters of information I/O.</p>
<p>As a side note, I happen to think, that such magnificent programing languages
like <a class="reference external" href="http://en.wikipedia.org/wiki/Haskell_(programming_language)">Haskell</a>
and similar non-procedural languages have not much chance of being widely
adopted. And this is not because of some perceived learning difficulties, but
simply owning to the unfortunate fact, that I/O functionality necessarily looks
very cumbersome when implemented in them. It’s not like procedural languages do
it so much better, simply correct I/O as it is already presents so many
challenges, that fitting it into additional language mandated abstract form does
it no good service as all.</p>
<section id="message-passing-interface">
<span id="mp-dev"></span><h2>Message passing interface<a class="headerlink" href="#message-passing-interface" title="Permalink to this heading">¶</a></h2>
<p>The most basic and ubiquitous I/O communication pattern is a message passing
interface. Messages are nothing more than finite sequences of bits exchanged
between local and remote parties. Even disregarding computers outright, we
may notice that oral or written conversations between humans still can be
described in terms of message passing. Nature knows some other ways to
communicate (chemical trails come to mind) but those have not made it into
computer engineering just yet.</p>
<p>Given a need to engage in information exchange with a remote party we can do
three basic things:</p>
<ol class="arabic simple">
<li><p>Establish the identity of the remote party using some form of address
literal.</p></li>
<li><p>Prepare a message by putting some bits together and send it over.</p></li>
<li><p>Designate an area of local memory to serve as mailbox and check it every now
and then to see if something (remotely originated message) had dropped in.</p></li>
</ol>
<p>Surprising, as it may be, there’s not much else to do, communication wise.</p>
<p>Atop of the basic pattern some convenient extensions are always possible.</p>
<dl class="simple">
<dt><strong>Blocking wait</strong></dt><dd><p>When waiting to receive a message, application can ask an operating system
to poll the mailbox on its behalf and conveniently do nothing in the meantime.
This is, of course, mostly useful on time-sharing operating systems.</p>
</dd>
<dt><strong>Request/reply</strong></dt><dd><p>Sometimes, the remote party will do something only if asked to. Single
interface entry point can be used by application to format a request message,
send it, wait for remote party to reply and return the reply as a result of
seemingly single operation. Ordinary file access on most operating systems
works roughly like this (it’s worth remembering how complex modern storage
devices actually are).</p>
</dd>
<dt><strong>Streaming</strong></dt><dd><p>Sometimes, I/O interaction is described in terms of continuous data stream.
However, streaming normally means rearranging (cutting and pasting) messages
to form other messages out of them. As some editing of messages in always
necessary, there appears to be no need to give streaming pattern any special
distinction.</p>
</dd>
</dl>
</section>
<section id="remote-memory-interface">
<span id="rm-dev"></span><h2>Remote memory interface<a class="headerlink" href="#remote-memory-interface" title="Permalink to this heading">¶</a></h2>
<p>Some remote parties happen to possess considerable amount of memory, taken in
most broad meaning of the word. It can either be semiconductor memory, similar
to local one, or magnetic medium, or even an optical imaging device. At any rate
it is very convenient to make this remote memory available to an application as
if it were a local one. While impossible in general (moving information around
requires time and effort) such memory mapping can be achieved in standardised,
application independent way, whereupon actual message passing can be delegated
to operating system or even hardware (as it is done on
<a class="reference external" href="http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access">NUMA platforms</a>).</p>
<p>Normally, remote memory access is an additional capability of otherwise usual
message passing interface. Unless a lot of hardware magic is employed, operation
of the remotely shared memory requires explicit synchronisation of interested
parties by means of predefined message exchange protocols. Therefore, when
mentioning remote memory interfaces, it is implied that those interfaces can be
operated like a pure message passing ones.</p>
<p><a class="reference external" href="http://github.com/oakad/oakad.github.com/issues#issue/2">General comments, corrections, objections?</a></p>
</section>
</section>
<div class="clearer"></div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<div>
<h3><a href="index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Brief discussion of input/output interface traits</a><ul>
<li><a class="reference internal" href="#message-passing-interface">Message passing interface</a></li>
<li><a class="reference internal" href="#remote-memory-interface">Remote memory interface</a></li>
</ul>
</li>
</ul>
</div>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/iotraits.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="nav-item nav-item-0"><a href="index.html">Nothing special</a> »</li>
<li class="nav-item nav-item-this"><a href="">Brief discussion of input/output interface traits</a></li>
</ul>
</div>
<div class="footer" role="contentinfo">
© <a href="copyright.html">Copyright</a> 2010 - 2023, Alex Dubov <oakad@yahoo.com>.
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 6.1.3.
</div>
</body>
</html>