什么是Erlang中的ref？

Question

完成此link

为了识别一个过程，我们将使用Pid.But什么时候应该使用ref？

我经常在发送/接收消息时看到这一点，但无法解释它在消息交互中扮演的角色。

Answer 1

引用documentation

  

引用是一个在Erlang运行时系统中唯一的术语，通过调用make_ref / 0创建。

这意味着这是特殊的数据类型，它不是整数，不是列表，也不是二进制。尤其是unique繁荣。它的设计主要是为了识别代码中的某些地方。 make_ref()，无论它在何处被调用，都会返回新值（当然，在size的边界内）。就像弗雷德在其书中描述的那样，它非常适合标记消息，并且能够识别我们收到的消息是否响应我们发送的消息。

Answer 2

作为对其他回复的补充，请注意参考：

• 不是随机值（只需启动一个类型为make_ref（）的几个 倍）
• 仅在一个VM中是唯一的（打开一个新VM并键入make_ref（） 多次，你会得到与上面相同的结果）尽管如此，你可以使用元组{node(),make_ref()}创建一个。

与文档没有差异，但我在过去做了一些错误的假设......：o）。感谢@Robert的纠正！

Answer 3

因为ref是唯一的，它可以识别收到的消息。

例如：

A,B two Actors, A want to known B's age

there are 2 solutions:

Method 1:  A send Msg({age}) to B,then B send result Msg({age,10})
but,before A receive this Msg,Actor C send Msg{age,20} to A,
then A got the wrong answer

Method 2: A send Msg({age,Ref}) to B,
no one knowns the Ref except A and B,
then A got the right answer from B.

Answer 4

免责声明：我的回答主要基于了解一些Erlang，特别是问题中提供的link。

---

使用引用的想法是唯一标识给定的消息，以便您可以匹配消息及其响应 - 假设响应包含在原始消息中发送的引用。

我们需要在使用重启的命名进程时识别消息，因为在这种情况下，由于并发性，我们不能依赖PID。如书中所示：

1. critic ! Message
2. critic收到
3. critic回复
4. critic去世
5. whereis失败
6. critic重新启动
7. 代码崩溃

或

1. critic ! Message
2. critic收到
3. critic回复
4. critic去世
5. critic重新启动
6. whereis选错了pid
7. 消息永不匹配

如果期望得到{Pid, Response}形式的响应，则存在交错，您将获得错误的PID或根本没有PID，从而使您的流程无法收到响应。这是使用重新启动的命名进程的结果：您知道它们的PID可能会在没有通知的情况下更改，无限次，因此将它们命名为方便发送消息。

使用唯一标识符来标记邮件可以完全避免此问题，因为您希望在响应中返回引用，而不是PID。

This question可能会解释为什么我在 unique 中使用斜体。这些参考文献并不是真正独一无二的，但对于实际目的而言非常独特。