What is ref in Erlang?

In complement to other responses, beware that a ref:

  • is not a random value (just start a VM an type make_ref(). several times)
  • is unique only in one VM (open a new VM and type make_ref() several times, you will get the same result as above) Nevertheless you can create one using a tuple {node(),make_ref()}.

No discrepancy with the documentation, but I made some wrong assumption in the past ... :o). Thanks @Robert for correction!


To quote documentation

A reference is a term which is unique in an Erlang runtime system, created by calling make_ref/0.

This means that this is special data type, it's not an integer, not a list, and not a binary. Especially with unique prosperity. It's designed mostly to recognize some places in code. make_ref(), no matter where it is called, will return new value (in boundaries of it's size of course). And just like Fred describes in it's book, it is great for tagging messages, and recognizing if message we receive is in response to one we just send.


Disclaimer: My answer is mostly based on Learn You Some Erlang, in particular the link provided in the question.

The idea of using references is to uniquely identify a given message, so that you can match the messages and their responses - given that the response includes the reference sent in the original message.

We need to identify messages when using named processes that restart because, in this scenario, we can't rely on PIDs, due to concurrency. As is given in the book:

  1. critic ! Message
  2. critic receives
  3. critic replies
  4. critic dies
  5. whereis fails
  6. critic is restarted
  7. code crashes

or

  1. critic ! Message
  2. critic receives
  3. critic replies
  4. critic dies
  5. critic is restarted
  6. whereis picks up wrong pid
  7. message never matches

There are interleavings where you'll get the wrong PID, or no PID at all, leaving your process unable to receive a response, if it was expecting a response of the form {Pid, Response}. This is a consequence of using named processes that restart: you know their PID might change without notice, unlimited times, hence naming them as a convenience to send them messages.

Using a unique identifier to tag the message avoids this problem altogether, because you expect the reference to be returned in the response, not a PID.

This question might explain why I use the italics in unique. The references are not really unique, but unique enough for practical purposes.

Tags:

Erlang

Recent Posts