[erlang-questions] Message send guarantees

[Jesper Louis Andersen]

On Thu, Jan 26, 2017 at 5:21 AM Dmitry Kakurin <dima_kakurin@REDACTED>
wrote:

> What aspect of implementation can cause such reordering? Could you give an
> example how this could happen? Maybe I'll be able to artificially create
> conditions where it would not happen. Or work around it in some other way.
> Please see below why.
>
>
>
A straightforward implementation would lock the mailbox of the receiving
process, put a message there, unlock the mailbox and proceed. In such a
system, the ordering is guaranteed because you have a happens-before
relationship on the message send. If the process is remote, TCP buffering
can reorder message arrival, so in general it is not good to structure
systems under the assumption that there is a happens-before relationship
between messages like this.

However, there is also the need to satisfy future possible implementations.
I could delay sending messages for a while and then send them as a large
batch later on. This is allowed in the semantics since the ! operator works
asynchronously. I could implement it as:

Allocate a new message.
Try a CAS operation on the target mailbox.
If the CAS operation fails, delay the attempt to later due to contention on
the target mailbox.

In this setting, there is no happens-before on '!', and thus messages may
be reordered.

If you start relying on internal implementation structure, chances are your
program subtly breaks later on. A good example was when the OTP team split
up the single timer wheel into multiple timer wheels. Before, there were an
order in which timers triggered and people relied on this order. But with
multiple timer wheels, reorderings are possible and their code broke.

My advice is to code for the rules of physics (causality). It tends to
produce the best results in the long run.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170126/36fa260c/attachment.htm>