-
Notifications
You must be signed in to change notification settings - Fork 5
/
the-hitchhikers-guide-to-concurrency.html
401 lines (297 loc) · 35.5 KB
/
the-hitchhikers-guide-to-concurrency.html
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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="keywords" content="Erlang, concurrency, parallelism, multicore, process, message passing, multiprocessing, fault-tolerant, system, distributed" />
<meta name="description" content="The basic concepts behind Erlang's message passing architecture for writing fault-tolerant systems. How to spawn new processes, send and receive messages and a few examples." />
<meta name="google-site-verification" content="mi1UCmFD_2pMLt2jsYHzi_0b6Go9xja8TGllOSoQPVU" />
<link rel="stylesheet" type="text/css" href="static/css/screen.css" media="screen" />
<link rel="stylesheet" type="text/css" href="static/css/sh/shCore.css" media="screen" />
<link rel="stylesheet" type="text/css" href="static/css/sh/shThemeLYSE2.css" media="screen" />
<link rel="stylesheet" type="text/css" href="static/css/print.css" media="print" />
<link href="rss" type="application/rss+xml" rel="alternate" title="LYSE news" />
<link rel="icon" type="image/png" href="favicon.ico" />
<link rel="apple-touch-icon" href="static/img/touch-icon-iphone.png" />
<link rel="apple-touch-icon" sizes="72x72" href="static/img/touch-icon-ipad.png" />
<link rel="apple-touch-icon" sizes="114x114" href="static/img/touch-icon-iphone4.png" />
<title>The Hitchhiker's Guide to Concurrency | Learn You Some Erlang for Great Good!</title>
</head>
<body>
<div id="wrapper">
<div id="header">
<h1>Learn you some Erlang</h1>
<span>for great good!</span>
</div> <!-- header -->
<div id="menu">
<ul>
<li><a href="content.html" title="Home">Home</a></li>
<li><a href="faq.html" title="Frequently Asked Questions">FAQ</a></li>
<li><a href="rss" title="Latest News">RSS</a></li>
<li><a href="static/erlang/learn-you-some-erlang.zip" title="Source Code">Code</a></li>
</ul>
</div><!-- menu -->
<div id="content">
<div class="noscript"><noscript>Hey there, it appears your Javascript is disabled. That's fine, the site works without it. However, you might prefer reading it with syntax highlighting, which requires Javascript!</noscript></div>
<h2>The Hitchhiker's Guide to Concurrency</h2>
<p>Far out in the uncharted backwaters of the unfashionable beginning of the 21st century lies a small subset of human knowledge.</p>
<p>Within this subset of human knowledge is an utterly insignificant little discipline whose Von Neumann-descended architecture is so amazingly primitive that it is still thought that RPN calculators are a pretty neat idea.</p>
<p>This discipline has — or rather had — a problem, which was this: most of the people studying it were unhappy for pretty much of the time when trying to write parallel software. Many solutions were suggested for this problem, but most of these were largely concerned with the handling of little pieces of logic called locks and mutexes and whatnot, which is odd because on the whole it wasn't the small pieces of logic that needed parallelism.</p>
<p>And so the problem remained; lots of people were mean, and most of them were miserable, even those with RPN calculators.</p>
<p>Many were increasingly of the opinion that they'd all made a big mistake in trying to add parallelism to their programming languages, and that no program should have ever left its initial thread.</p>
<div class="note">
<p><strong>Note:</strong> parodying The Hitchhiker's Guide to the Galaxy is fun. Read the book if you haven't already. It's good!</p>
</div>
<h3><a class="section" name="dont-panic">Don't Panic</a></h3>
<p>Hi. Today (or whatever day you are reading this, even tomorrow), I'm going to tell you about concurrent Erlang. Chances are you've read about or dealt with concurrency before. <img class="left" src="static/img/fat-guy.png" width="230" height="204" alt="A fat guy at the computer" /> You might also be curious about the emergence of multi-core programming. Anyway, the probabilities are high that you're reading this book because of all this talk about concurrency going on these days.</p>
<p>A warning though; this chapter is mostly theoric. If you have a headache, a distaste for programming language history or just want to program, you might be better off skipping to the <a class="chapter" href="the-hitchhikers-guide-to-concurrency.html#thanks-for-all-the-fish">end of the chapter</a> or skip to the next one (where more practical knowledge is shown.)</p>
<p>I've already explained in the book's intro that Erlang's concurrency was based on message passing and the actor model, with the example of people communicating with nothing but letters. I'll explain it more in details again later, but first of all, I believe it is important to define the difference between <em>concurrency</em> and <em>parallelism</em>.</p>
<p>In many places both words refer to the same concept. They are often used as two different ideas in the context of Erlang. For many Erlangers, concurrency refers to the idea of having many actors running independently, but not necessarily all at the same time. Parallelism is having actors running exactly at the same time. I will say that there doesn't seem to be any consensus on such definitions around various areas of computer science, but I will use them in this manner in this text. Don't be surprised if other sources or people use the same terms to mean different things.</p>
<p>This is to say Erlang had concurrency from the beginning, even when everything was done on a single core processor in the '80s. Each Erlang process would have its own slice of time to run, much like desktop applications did before multi-core systems.</p>
<p>Parallelism was still possible back then; all you needed to do was to have a second computer running the code and communicating with the first one. Even then, only two actors could be run in parallel in this setup. Nowadays, multi-core systems allows for parallelism on a single computer (with some industrial chips having many dozens of cores) and Erlang takes full advantage of this possibility.</p>
<div class="note koolaid">
<p><strong>Don't drink too much Kool-Aid:</strong><br />
The distinction between concurrency and parallelism is important to make, because many programmers hold the belief that Erlang was ready for multi-core computers years before it actually was. Erlang was only adapted to true <a class="external" href="http://en.wikipedia.org/wiki/Symmetric_multiprocessing">symmetric multiprocessing</a> in the mid 2000s and only got most of the implementation right with the R13B release of the language in 2009. Before that, <acronym title="Symetric Multiprocessing">SMP</acronym> often had to be disabled to avoid performance losses. To get parallelism on a multicore computer without SMP, you'd start many instances of the VM instead.</p>
<p>An interesting fact is that because Erlang concurrency is all about isolated processes, it took no conceptual change at the language level to bring true parallelism to the language. All the changes were transparently done in the VM, away from the eyes of the programmers.</p>
</div>
<h3><a class="section" name="concepts-of-concurrency">Concepts of Concurrency</a></h3>
<img class="right" src="static/img/erlang-the-movie.png" width="305" height="276" alt="Joe Armstrong, as in 'Erlang - The Movie" title="Erlang, the movie!" />
<p>Back in the day, Erlang's development as a language was extremely quick with frequent feedback from engineers working on telephone switches in Erlang itself. These interactions proved processes-based concurrency and asynchronous message passing to be a good way to model the problems they faced. Moreover, the telephony world already had a certain culture going towards concurrency before Erlang came to be. This was inherited from PLEX, a language created earlier at Ericsson, and AXE, a switch developed with it. Erlang followed this tendency and attempted to improve on previous tools available.</p>
<p>Erlang had a few requirements to satisfy before being considered good. The main ones were being able to scale up and support many thousands of users across many switches, and then to achieve high reliability—to the point of never stopping the code.</p>
<h4>Scalability</h4>
<p>I'll focus on the scaling first. Some properties were seen as necessary to achieve scalability. Because users would be represented as processes which only reacted upon certain events (i.e.: receiving a call, hanging up, etc.), an ideal system would support processes doing small computations, switching between them very quickly as events came through. To make it efficient, it made sense for processes to be started very quickly, to be destroyed very quickly and to be able to switch them really fast. Having them lightweight was mandatory to achieve this. It was also mandatory because you didn't want to have things like process pools (a fixed amount of processes you split the work between.) Instead, it would be much easier to design programs that could use as many processes as they need.</p>
<p>Another important aspect of scalability is to be able to bypass your hardware's limitations. There are two ways to do this: make the hardware better, or add more hardware. The first option is useful up to a certain point, after which it becomes extremely expensive (i.e.: buying a super computer). The second option is usually cheaper and requires you to add more computers to do the job. This is where distribution can be useful to have as a part of your language.</p>
<p>Anyway, to get back to small processes, because telephony applications needed a lot of reliability, it was decided that the cleanest way to do things was to forbid processes from sharing memory. Shared memory could leave things in an inconsistent state after some crashes (especially on data shared across different nodes) and had some complications. Instead, processes should communicate by sending messages where all the data is copied. This would risk being slower, but safer.</p>
<h4>Fault-tolerance</h4>
<p>This leads us on the second type of requirements for Erlang: reliability. The first writers of Erlang always kept in mind that failure is common. You can try to prevent bugs all you want, but most of the time some of them will still happen. In the eventuality bugs don't happen, nothing can stop hardware failures all the time. The idea is thus to find good ways to handle errors and problems rather than trying to prevent them all.</p>
<p>It turns out that taking the design approach of multiple processes with message passing was a good idea, because error handling could be grafted onto it relatively easily. Take lightweight processes (made for quick restarts and shutdowns) as an example. Some studies proved that the main sources of downtime in large scale software systems are intermittent or transient bugs (<a class="external" href="http://dslab.epfl.ch/pubs/crashonly.pdf">source</a>). Then, there's a principle that says that errors which corrupt data should cause the faulty part of the system to die as fast as possible in order to avoid propagating errors and bad data to the rest of the system. Another concept here is that there exist many different ways for a system to terminate, two of which are clean shutdowns and crashes (terminating with an unexpected error).</p>
<p>Here the worst case is obviously the crash. A safe solution would be to make sure all crashes are the same as clean shutdowns: this can be done through practices such as shared-nothing and single assignment (which isolates a process' memory), avoiding <a class="external" href="http://en.wikipedia.org/wiki/Lock_(computer_science)">locks</a> (a lock could happen to not be unlocked during a crash, keeping other processes from accessing the data or leaving data in an inconsistent state) and other stuff I won't cover more, but were all part of Erlang's design. Your ideal solution in Erlang is thus to kill processes as fast as possible to avoid data corruption and transient bugs. Lightweight processes are a key element in this. Further error handling mechanisms are also part of the language to allow processes to monitor other processes (which are described in the <a class="chapter" href="errors-and-processes.html">Errors and Processes</a> chapter), in order to know when processes die and to decide what to do about it.</p>
<p>Supposing restarting processes real fast is enough to deal with crashes, the next problem you get is hardware failures. How do you make sure your program keeps running when someone kicks the computer it's running on? <img class="left" src="static/img/cacti-laser.png" width="261" height="237" alt="A server (HAL) protected by cacti and lasers" title="I'm pretty sure this would work" /> Although a fancy defense mechanism comprising laser detection and strategically placed cacti could do the job for a while, it would not last forever. The hint is simply to have your program running on more than one computer at once, something that was needed for scaling anyway. This is another advantage of independent processes with no communication channel outside message passing. You can have them working the same way whether they're local or on a different computer, making fault tolerance through distribution nearly transparent to the programmer.</p>
<p>Being distributed has direct consequences on how processes can communicate with each other. One of the biggest hurdles of distribution is that you can't assume that because a node (a remote computer) was there when you made a function call, it will still be there for the whole transmission of the call or that it will even execute it correctly. Someone tripping over a cable or unplugging the machine would leave your application hanging. Or maybe it would make it crash. Who knows?</p>
<p>Well it turns out the choice of asynchronous message passing was a good design pick there too. Under the processes-with-asynchronous-messages model, messages are sent from one process to a second one and stored in a <em>mailbox</em> inside the receiving process until they are taken out to be read. It's important to mention that messages are sent without even checking if the receiving process exists or not because it would not be useful to do so. As implied in the previous paragraph, it's impossible to know if a process will crash between the time a message is sent and received. And if it's received, it's impossible to know if it will be acted upon or again if the receiving process will die before that. Asynchronous messages allow safe remote function calls because there is no assumption about what will happen; the programmer is the one to know. If you need to have a confirmation of delivery, you have to send a second message as a reply to the original process. This message will have the same safe semantics, and so will any program or library you build on this principle.</p>
<h4>Implementation</h4>
<p>Alright, so it was decided that lightweight processes with asynchronous message passing were the approach to take for Erlang. How to make this work? Well, first of all, the operating system can't be trusted to handle the processes. Operating systems have many different ways to handle processes, and their performance varies a lot. Most if not all of them are too slow or too heavy for what is needed by standard Erlang applications. By doing this in the VM, the Erlang implementers keep control of optimization and reliability. Nowadays, Erlang's processes take about 300 words of memory each and can be created in a matter of microseconds—not something doable on major operating systems these days.</p>
<img class="right explanation" src="static/img/schedulers.png" width="292" height="298" alt="Erlang's run queues across cores" />
<p>To handle all these potential processes your programs could create, the VM starts one thread per core which acts as a <em>scheduler</em>. Each of these schedulers has a <em>run queue</em>, or a list of Erlang processes on which to spend a slice of time. When one of the schedulers has too many tasks in its run queue, some are migrated to another one. This is to say each Erlang VM takes care of doing all the load-balancing and the programmer doesn't need to worry about it. There are some other optimizations that are done, such as limiting the rate at which messages can be sent on overloaded processes in order to regulate and distribute the load.</p>
<p>All the hard stuff is in there, managed for you. That is what makes it easy to go parallel with Erlang. Going parallel means your program should go twice as fast if you add a second core, four times faster if there are 4 more and so on, right? It depends. Such a phenomenon is named <em>linear scaling</em> in relation to speed gain vs. the number of cores or processors (see the graph below.) In real life, there is no such thing as a free lunch (well, there are at funerals, but someone still has to pay, somewhere).</p>
<h3><a class="section" name="not-entirely-unlike">Not Entirely Unlike Linear Scaling</a></h3>
<p>The difficulty of obtaining linear scaling is not due to the language itself, but rather to the nature of the problems to solve. Problems that scale very well are often said to be <em>embarrassingly parallel</em>. If you look for embarrassingly parallel problems on the Internet, you're likely to find examples such as ray-tracing (a method to create 3D images), brute-forcing searches in cryptography, weather prediction, etc.</p>
<p>From time to time, people then pop up in IRC channels, forums or mailing lists asking if Erlang could be used to solve that kind of problem, or if it could be used to program on a <a class="external" href="http://en.wikipedia.org/wiki/Graphics_Processing_Unit" title="Graphics Processing Unit">GPU</a>. The answer is almost always 'no'. The reason is relatively simple: all these problems are usually about numerical algorithms with lots of data crunching. Erlang is not very good at this.</p>
<p>Erlang's embarrassingly parallel problems are present at a higher level. Usually, they have to do with concepts such as chat servers, phone switches, web servers, message queues, web crawlers or any other application where the work done can be represented as independent logical entities (actors, anyone?). This kind of problem can be solved efficiently with close-to-linear scaling.</p>
<p>Many problems will never show such scaling properties. In fact, you only need one centralized sequence of operations to lose it all. <strong>Your parallel program only goes as fast as its slowest sequential part</strong>. An example of that phenomenon is observable any time you go to a mall. Hundreds of people can be shopping at once, rarely interfering with each other. Then once it's time to pay, queues form as soon as there are fewer cashiers than there are customers ready to leave.</p>
<p>It would be possible to add cashiers until there's one for each customer, but then you would need a door for each customer because they couldn't get inside or outside the mall all at once.</p>
<p>To put this another way, even though customers could pick each of their items in parallel and basically take as much time to shop whether they're alone or a thousand in the store, they would still have to wait to pay. Therefore their shopping experience can never be shorter than the time it takes them to wait in the queue and pay.</p>
<p>A generalisation of this principle is called <a class="external" href="http://en.wikipedia.org/wiki/Amdahl's_law">Amdahl's Law</a>. It indicates how much of a speedup you can expect your system to have whenever you add parallelism to it, and in what proportion: </p>
<img class="center explanation" src="static/img/amdahl.png" width="407" height="325" alt="Graphic showing a program's speedup relative to how much of it is parallel on many cores" title="Thanks wikimedia user Jgonion for the public domain graph" />
<!-- source for the image: http://commons.wikimedia.org/wiki/File:AmdahlsLaw.png -->
<p>According to Amdahl's law, code that is 50% parallel can never get faster than twice what it was before, and code that is 95% parallel can theoretically be expected to be about 20 times faster if you add enough processors. What's interesting to see on this graph is how getting rid of the last few sequential parts of a program allows a relatively huge theoretical speedup compared to removing as much sequential code in a program that is not very parallel to begin with.</p>
<div class="note koolaid">
<p><strong>Don't drink too much Kool-Aid:</strong><br />
Parallelism is <em>not</em> the answer to every problem. In some cases, going parallel will even slow down your application. This can happen whenever your program is 100% sequential, but still uses multiple processes.</p>
<p>One of the best examples of this is the <em>ring benchmark</em>. A ring benchmark is a test where many thousands of processes will pass a piece of data to one after the other in a circular manner. Think of it as a <a class="external" href="http://en.wikipedia.org/wiki/Telephone_game">game of telephone</a> if you want. In this benchmark, only one process at a time does something useful, but the Erlang VM still spends time distributing the load accross cores and giving every process its share of time.</p>
<p>This plays against many common hardware optimizations and makes the VM spend time doing useless stuff. This often makes purely sequential applications run much slower on many cores than on a single one. In this case, disabling symmetric multiprocessing (<code>$ erl -smp disable</code>) might be a good idea.</p>
</div>
<h3><a class="section" name="thanks-for-all-the-fish">So long and thanks for all the fish!</a></h3>
<p>Of course, this chapter would not be complete if it wouldn't show the three primitives required for concurrency in Erlang: spawning new processes, sending messages, and receiving messages. In practice there are more mechanisms required for making really reliable applications, but for now this will suffice.</p>
<p>I've skipped around the issue a whole lot and I have yet to explain what a process really is. It's in fact nothing but a function. That's it. It runs a function and once it's done, it disappears. Technically, a process also has some hidden state (such as a mailbox for messages), but functions are enough for now.</p>
<p>To start a new process, Erlang provides the function <code>spawn/1</code>, which takes a single function and runs it:</p>
<pre class="brush:eshell">
1> F = fun() -> 2 + 2 end.
#Fun<erl_eval.20.67289768>
2> spawn(F).
<0.44.0>
</pre>
<p>The result of <code>spawn/1</code> (<code><0.44.0></code>) is called a <em>Process Identifier</em>, often just written <em>PID</em>, <em>Pid</em>, or <em>pid</em> by the community. The process identifier is an arbitrary value representing any process that exists (or might have existed) at some point in the VM's life. It is used as an address to communicate with the process.</p>
<p>You'll notice that we can't see the result of the function <var>F</var>. We only get its pid. That's because processes do not return anything.</p>
<p>How can we see the result of F then? Well, there are two ways. The easiest one is to just output whatever we get:</p>
<pre class="brush:eshell">
3> spawn(fun() -> io:format("~p~n",[2 + 2]) end).
4
<0.46.0>
</pre>
<p>This isn't practical for a real program, but it is useful for seeing how Erlang dispatches processes. Fortunately, using <code>io:format/2</code> is enough to let us experiment. We'll start 10 processes real quick and pause each of them for a while with the help of the function <code>timer:sleep/1</code>, which takes an integer value <var>N</var> and waits for <var>N</var> milliseconds before resuming code. After the delay, the value present in the process is output.</p>
<pre class="brush:eshell">
4> G = fun(X) -> timer:sleep(10), io:format("~p~n", [X]) end.
#Fun<erl_eval.6.13229925>
5> [spawn(fun() -> G(X) end) || X <- lists:seq(1,10)].
[<0.273.0>,<0.274.0>,<0.275.0>,<0.276.0>,<0.277.0>,
<0.278.0>,<0.279.0>,<0.280.0>,<0.281.0>,<0.282.0>]
2
1
4
3
5
8
7
6
10
9
</pre>
<p>The order doesn't make sense. Welcome to parallelism. Because the processes are running at the same time, the ordering of events isn't guaranteed anymore. That's because the Erlang VM uses many tricks to decide when to run a process or another one, making sure each gets a good share of time. Many Erlang services are implemented as processes, including the shell you're typing in. Your processes must be balanced with those the system itself needs and this might be the cause of the weird ordering.</p>
<div class="note">
<p><strong>Note:</strong> the results are similar whether symmetric multiprocessing is enabled or not. To prove it, you can just test it out by starting the Erlang VM with <code>$ erl -smp disable</code>.</p>
<p>To see if your Erlang VM runs with or without SMP support in the first place, start a new VM without any options and look for the first line output. If you can spot the text <samp>[smp:2:2] [rq:2]</samp>, it means you're running with SMP enabled, and that you have 2 run queues (<samp>rq</samp>, or schedulers) running on two cores. If you only see <samp>[rq:1]</samp>, it means you're running with SMP disabled.</p>
<p>If you wanted to know, <samp>[smp:2:2]</samp> means there are two cores available, with two schedulers. <samp>[rq:2]</samp> means there are two run queues active. In earlier versions of Erlang, you could have multiple schedulers, but with only one shared run queue. Since R13B, there is one run queue per scheduler by default; this allows for better parallelism.</p>
</div>
<p>To prove the shell itself is implemented as a regular process, I'll use the BIF <code>self/0</code>, which returns the pid of the current process:</p>
<pre class="brush:eshell">
6> self().
<0.41.0>
7> exit(self()).
** exception exit: <0.41.0>
8> self().
<0.285.0>
</pre>
<p>And the pid changes because the process has been restarted. The details of how this works will be seen later. For now, there's more basic stuff to cover. The most important one right now is to figure out how to send messages around, because nobody wants to be stuck with outputting the resulting values of processes all the time, and then entering them by hand in other processes (at least I know I don't.)</p>
<p>The next primitive required to do message passing is the operator <code>!</code>, also known as the <em>bang</em> symbol. On the left-hand side it takes a pid and on the right-hand side it takes any Erlang term. The term is then sent to the process represented by the pid, which can access it:</p>
<pre class="brush:eshell">
9> self() ! hello.
hello
</pre>
<p>The message has been put in the process' mailbox, but it hasn't been read yet. The second <code>hello</code> shown here is the return value of the send operation. This means it is possible to send the same message to many processes by doing:</p>
<pre class="brush:eshell">
10> self() ! self() ! double.
double
</pre>
<p>Which is equivalent to <code>self() ! (self() ! double)</code>. A thing to note about a process' mailbox is that the messages are kept in the order they are received. Every time a message is read it is taken out of the mailbox. Again, this is a bit similar to the introduction's example with people writing letters.</p>
<img class="center explanation" src="static/img/hello.png" width="362" height="143" alt="Message passing explained as a drawing, again" title="the guy on the right doesn't pick on receives" />
<p>To see the contents of the current mailbox, you can use the <code>flush()</code> command while in the shell:</p>
<pre class="brush:eshell">
11> flush().
Shell got hello
Shell got double
Shell got double
ok
</pre>
<p>This function is just a shortcut that outputs received messages. This means we still can't bind the result of a process to a variable, but at least we know how to send it from a process to another one and check if it's been received.</p>
<p>Sending messages that nobody will read is as useful as writing emo poetry; not a whole lot. This is why we need the <code>receive</code> statement. Rather than playing for too long in the shell, we'll write a <a class="source" href="static/erlang/dolphins.erl">short program</a> about dolphins to learn about it:</p>
<pre class="brush:erl">
-module(dolphins).
-compile(export_all).
dolphin1() ->
receive
do_a_flip ->
io:format("How about no?~n");
fish ->
io:format("So long and thanks for all the fish!~n");
_ ->
io:format("Heh, we're smarter than you humans.~n")
end.
</pre>
<p>As you can see, <code>receive</code> is syntactically similar to <code>case ... of</code>. In fact, the patterns work exactly the same way except they bind variables coming from messages rather than the expression between <code>case</code> and <code>of</code>. Receives can also have guards:</p>
<pre class="brush:erl">
receive
Pattern1 when Guard1 -> Expr1;
Pattern2 when Guard2 -> Expr2;
Pattern3 -> Expr3
end
</pre>
<p>We can now compile the above module, run it, and start communicating with dolphins:</p>
<pre class="brush:eshell">
11> c(dolphins).
{ok,dolphins}
12> Dolphin = spawn(dolphins, dolphin1, []).
<0.40.0>
13> Dolphin ! "oh, hello dolphin!".
Heh, we're smarter than you humans.
"oh, hello dolphin!"
14> Dolphin ! fish.
fish
15>
</pre>
<p>Here we introduce a new way of spawning with <code>spawn/3</code>. Rather than taking a single function, <code>spawn/3</code> takes the module, function and its arguments as its own arguments. Once the function is running, the following events take place:</p>
<ol>
<li>The function hits the <code>receive</code> statement. Given the process' mailbox is empty, our dolphin waits until it gets a message;</li>
<li>The message <samp>"oh, hello dolphin!"</samp> is received. The function tries to pattern match against <code>do_a_flip</code>. This fails, and so the pattern <code>fish</code> is tried and also fails. Finally, the message meets the catch-all clause (<code>_</code>) and matches.</li>
<li>The process outputs the message <samp>"Heh, we're smarter than you humans."</samp></li>
</ol>
<p>Then it should be noted that if the first message we sent worked, the second provoked no reaction whatsoever from the process <code><0.40.0></code>. This is due to the fact once our function output <samp>"Heh, we're smarter than you humans."</samp>, it terminated and so did the process. We'll need to restart the dolphin:</p>
<pre class="brush:eshell">
8> f(Dolphin).
ok
9> Dolphin = spawn(dolphins, dolphin1, []).
<0.53.0>
10> Dolphin ! fish.
So long and thanks for all the fish!
fish
</pre>
<p>And this time the fish message works. Wouldn't it be useful to be able to receive a reply from the dolphin rather than having to use <code>io:format/2</code>? Of course it would (why am I even asking?) I've mentioned earlier in this chapter that the only manner to know if a process had received a message is to send a reply. Our dolphin process will need to know who to reply to. This works like it does with the postal service. If we want someone to know answer our letter, we need to add our address. In Erlang terms, this is done by packaging a process' pid in a tuple. The end result is a message that looks a bit like <code>{Pid, Message}</code>. Let's create a new dolphin function that will accept such messages:</p>
<pre class="brush:erl">
dolphin2() ->
receive
{From, do_a_flip} ->
From ! "How about no?";
{From, fish} ->
From ! "So long and thanks for all the fish!";
_ ->
io:format("Heh, we're smarter than you humans.~n")
end.
</pre>
<p>As you can see, rather than accepting <code>do_a_flip</code> and <code>fish</code> for messages, we now require a variable <var>From</var>. That's where the process identifier will go.</p>
<pre class="brush:eshell">
11> c(dolphins).
{ok,dolphins}
12> Dolphin2 = spawn(dolphins, dolphin2, []).
<0.65.0>
13> Dolphin2 ! {self(), do_a_flip}.
{<0.32.0>,do_a_flip}
14> flush().
Shell got "How about no?"
ok
</pre>
<p>It seems to work pretty well. We can receive replies to messages we sent (we need to add an address to each message), but we still need to start a new process for each call. Recursion is the way to solve this problem. We just need the function to call itself so it never ends and always expects more messages. Here's a function <code>dolphin3/0</code> that puts this in practice:</p>
<pre class="brush:erl">
dolphin3() ->
receive
{From, do_a_flip} ->
From ! "How about no?",
dolphin3();
{From, fish} ->
From ! "So long and thanks for all the fish!";
_ ->
io:format("Heh, we're smarter than you humans.~n"),
dolphin3()
end.
</pre>
<p>Here the catch-all clause and the <code>do_a_flip</code> clause both loop with the help of <code>dolphin3/0</code>. Note that the function will not blow the stack because it is tail recursive. As long as only these messages are sent, the dolphin process will loop indefinitely. However, if we send the <code>fish</code> message, the process will stop:</p>
<pre class="brush:eshell">
15> Dolphin3 = spawn(dolphins, dolphin3, []).
<0.75.0>
16> Dolphin3 ! Dolphin3 ! {self(), do_a_flip}.
{<0.32.0>,do_a_flip}
17> flush().
Shell got "How about no?"
Shell got "How about no?"
ok
18> Dolphin3 ! {self(), unknown_message}.
Heh, we're smarter than you humans.
{<0.32.0>,unknown_message}
19> Dolphin3 ! Dolphin3 ! {self(), fish}.
{<0.32.0>,fish}
20> flush().
Shell got "So long and thanks for all the fish!"
ok
</pre>
<p>And that should be it for <a class="source" href="static/erlang/dolphins.erl">dolphins.erl</a>. As you see, it does respect our expected behavior of replying once for every message and keep going afterwards, except for the <code>fish</code> call. The dolphin got fed up with our crazy human antics and left us for good.</p>
<img class="center" src="static/img/dolphin.png" width="479" height="432" alt="A man asking a dolphin to do a flip. The dolphin (dressed like the fonz) replies 'how about no?'" />
<p>There you have it. This is the core of all of Erlang's concurrency. We've seen processes and basic message passing. There are more concepts to see in order to make truly useful and reliable programs. We'll see some of them in the next chapter, and more in the chapters after that.</p>
<ul class="navigation">
<li><a href="a-short-visit-to-common-data-structures.html" title="Previous chapter">< Previous</a></li>
<li><a href="contents.html" title="Index">Index</a></li>
<li><a href="more-on-multiprocessing.html" title="Next chapter">Next ></a></li>
</ul>
</div><!-- content -->
<div id="footer">
<a href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License Details"><img src="static/img/cc.png" width="88" height="31" alt="Creative Commons Attribution Non-Commercial No Derivative License" /></a>
<p>Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution Non-Commercial No Derivative License</p>
</div> <!-- footer -->
</div> <!-- wrapper -->
<div id="grass" />
<script type="text/javascript" src="static/js/shCore.js"></script>
<script type="text/javascript" src="static/js/shBrushErlang2.js%3F11"></script>
<script type="text/javascript">
SyntaxHighlighter.defaults.gutter = false;
SyntaxHighlighter.all();
</script>
</body>
</html>