erlang并发编程和进程通信_erlang 并发

进程

erlang的并发编程简单易用而且轻量，只需通过spawn函数调用另一个函数即可，可谓开箱即用。其参数为

spawn(Module, Fucntion, Args) -> pid() 

其中Module为模型名；Function为函数名；Args为Function的参数。返回值pid()表示进程号。下面写一个脚本

-module(spawnTest). -export([start/0, say/2]). say(What, 0) -> done; say(What, Times) -> io:format("~p~n", [What]), say(What, Times - 1). start() -> spawn(spawnTest, say, [hello, 3]), spawn(spawnTest, say, [goodbye, 3]). 

编译并执行，结果如下，可见hello和goodbye之间的输出是交替的

1> c("spawnTest"). { 
   ok,spawnTest} 2> spawnTest:start(). hello goodbye hello goodbye <0.88.0> hello goodbye hello goodbye 

其中<0.88.0>是进程标识符，这个标识符是start函数返回的。所以这个程序看上去只有两个进程，交替打印出say和hello，但实际上，start()也是一个进程，其返回值是最后一行语句，即spawn…goodbye…的返回值。所以从上面的结果来看，两个spawnTest函数执行到一半的时候，start()迎来了生命周期的尾声。

消息传递

一般在编程语言中，线程和进程是两个不同的概念，前者是最小执行单元，可以粗暴地理解为一个函数。一个程序中可以有多个线程，这些线程共用一片内存，只是执行时并不按照调用的顺序，而是并发工作。进程则不然，每个进程都是一个独立运行的程序，拥有自己独有的内存区域，除非用特殊的手段让二者共享，否则彼此不通往来。

而在erlang中，spawn开启的是进程，彼此之间需要通过特殊的手段才能通信，这个特殊手段就是!，erlang进程通信的基本语法为

Pid ! Message 

其中Pid为进程的标识符，Message为发送的信息内容。这行代码的整体含义，就是向标识符为Pid的进程发送Message。

有发送自然要有接收，erlang接收信息需要一个程序块，基本格式为

receive Pattern1 -> ... Pattern2 -> ... ... end 

其中receive即接收函数，Pattern为被匹配的模式，简单理解就是发送者发送的内容。与普通函数在参数传入后的模式匹配雷同。

下面就实战体验一下

-module(comTest). -export([start/0, pidA/2, pidB/0]). pidA(0, PID) -> PID ! finished, io:format("A: finished~n", []); pidA(N, PID) -> % self() 返回自身的进程号 PID ! { 
   pidA, self()}, receive pidB -> io:format("A: received B~n", []) end, pidA(N - 1, PID). pidB() -> receive finished -> io:format("B: A finished~n", []); { 
   pidA, PID} -> io:format("B: received A~n", []), PID ! pidB, pidB() end. start() -> B_PID = spawn(comTest, pidB, []), spawn(comTest, pidA, [3, B_PID]). 

效果如下

1> c(comTest).
{ok,comTest}
2> comTest:start().
B: received A
<0.88.0>
A: received B
B: received A
3> A: received B
3> B: received A
3> A: received B
3> A: finished
3> B: A finished```

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/elixirbfbc/2412.html