tags:

views:

168

answers:

3

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 ;)

+2  A: 

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.

Pointy
+1, thanks Pointy. Keeping tabs on time order is an option. I suppose absolute order is almost impossible. Good answer! My messages shall come with a response back to the originating process. Still, does Erlang sync clocks?
Aiden Bell
+1  A: 

Per the erlang reference manual:

[Recieve] receives messages sent to the process using the send operator (!). The patterns Pattern are sequentially matched against the first message in time order in the mailbox, then the second, and so on.

Messages are processed serially per process.

Abtin Forouzandeh
+1, ah there it is :P What if the timestamp is "sent time" and nodes clocks have skew; In a high traffic environment it matters, does the Erlang VM/libs take this into account?
Aiden Bell
+8  A: 

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.)

cthulahoops
+1, a good solid answer. My thinking on the message passing is much clearer now that if A and B send many messages to C then no order (of the union of A and B's messages) is concrete. Something to factor into 'placement of concerns' in the design I think.
Aiden Bell
Joe Armstrong makes an analogy (http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html) which I really like. The ordering guarantees you get are exactly the same as with a group of people talking to each other.
cthulahoops
@cthulahoops - Great link, thanks!
Aiden Bell