Time order of messages

Question

Read (skimmed enough to get coding) through Erlang Programming and Programming Erlang.

One question, which is as simple as it sounds:

If you have a process Pid1 on machine m1 and a billion million messages are sent to Pid1, are messages handled in parallel by that process (I get the impression no) and(answered below)

is there any guarantee of order when processing messages? ie. Received in order sent? If so, how is clock skew handled in high traffic situations for ordering?

Coming from the whole C/Thread pools/Shared State background ... I want to get this concrete. I understand distributing an application, but want to ensure the 'raw bones' are what I expect before building processes and distributing workload.

Also, am I right in thinking the whole world is currently flicking through Erlang texts ;)

Answer 1

If process A sends two messages to process B, then the two messages are guaranteed to arrive in the order they are sent.

If process A sends a message to process B and then a message to process C, there's no guarantee as to the ordering in which they are received.

Similarly, if processes A & B send messages to C, there's no guarantee as to the order in which the messages are received.

It's a fundamental property of the message passing model the ordering of calculations in different processes is undefined, you can only meaningfully speak about ordering where a message send is involved. One consequence of the above rules is that if A sends a message to C, then a message to B, and on receipt of the message B sends to C, then C can receive the two messages in any order. (In practice, I suspect this never reverses on a single node, but could easily happen if the three processes are on different nodes.)

Answer 2

Messages are not handled in parallel; it's just one process, after all.

As to messaged ordering: the message queue is scanned in "time order" (oldest to newest). I think I recall a mailing list discussion a long time ago wherein somebody clarified that the timestamp is that of the messages origination (that is, the time at which it was sent), but I can't remember too clearly and I can't find any references to that online.

Note that your receive statement can perform matching on the head of the incoming message queue, which of course would allow a receiver to pick off incoming messages out of (temporal) order.