[erlang-questions] Message order and exit(Reason)
Dmitrii Dimandt
What I wanna know if we can be shure that the process A will receive 'msg' and only after It {'EXIT', Pid, reason} will come ? Can we predict the ordering of msgs? I can't found any proofs in documentation, but I guess that it will work that way, but I need some proofs. Don't want to have race condition here.
Thomas Lindgren
10.8 Is the order of message reception guaranteed?
From: Dmitrii Dimandt <dmi...@dmitriid.com>
To: Erlang Questions <erlang-q...@erlang.org>
Sent: Monday, January 28, 2013 10:00 AM
Subject: [erlang-questions] Message order and exit(Reason)
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Richard Carlsson
(never finished) Standard Erlang Specification Draft by Barklund and
Virding. In brief, Thomas is right: with regards to propagation and
order, exit messages are handled like regular messages. In fact, both
are instances of what the spec calls Signals, and the ordering
guarantees are valid for all Signals, not just messages. The spec lists
the following signals:
Messages
Exit signals
Link requests
Unlink requests
Group leader request
Info request
Suspend/resume request
Trace/notrace request
since the spec is quite old, it is possible that there are now other
examples of signals in the system, or that some of the above are
obsolete. But the ordering guarantees means that the following code will
work as expected:
link(PidA),
exit(reason).
signal will arrive after the message.
/Richard
On 2013-01-28 10:24 , Thomas Lindgren wrote:
>
> Hi Dmitrii,
>
> I think the following means that if A sends M1, M2 to B, then B will
> receive M1, M2 in the order of sending. It's not explicitly stated that
> exit messages are handled the same way as regular messages, though I
> think the default assumption should be that they are. Those here who
> have worked on model checking and whatnot, feel free to expound.
>
>
> 10.8 Is the order of message reception guaranteed?
>
> Yes, but only within one process.
> If there is a live process and you send it message A and then message B,
> it's guaranteed that if message B arrived, message A arrived before it.
> On the other hand, imagine processes P, Q and R. P sends message A to Q,
> and then message B to R. There is no guarantee that A arrives before B.
> (Distributed Erlang would have a pretty tough time if this was required!)
>
> http://www.erlang.org/faq/academic.html
>
> Best,
> Thomas
>
> *From:* Dmitrii Dimandt <dmi...@dmitriid.com>
> *To:* Erlang Questions <erlang-q...@erlang.org>
> *Sent:* Monday, January 28, 2013 10:00 AM
> *Subject:* [erlang-questions] Message order and exit(Reason)
> Hi all,
>
> We've had a semi-heated discussion in Russian community over this
> question: http://stackoverflow.com/questions/14556109/race-condition-between-trap-exit-exit-msg-and-common-msg
>
> The question is as following: Assume we have processes A and B which
> are linked. Process's A flag trap_exit is set to true. Let B process
> send a msg to A and then exit:
>
> PidA ! 'msg',
> exit(reason).
>
> What I wanna know if we can be shure that the process A will receive
> 'msg' and only after It {'EXIT', Pid, reason} will come ? Can
> we predict the ordering of msgs? I can't found any proofs in
> documentation, but I guess that it will work that way, but I need
> some proofs. Don't want to have race condition here.
>
>
> Can anyone with the intimate knowledge of Erlang internals shed some
> light on this?
>
> Thanks!
>
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions
Jesper Louis Andersen
On Jan 28, 2013, at 10:58 AM, Richard Carlsson <carlsson...@gmail.com> wrote:
> The only place I seem to find this actually described is in the old (never finished) Standard Erlang Specification Draft by Barklund and Virding. In brief, Thomas is right: with regards to propagation and order, exit messages are handled like regular messages. In fact, both are instances of what the spec calls Signals, and the ordering guarantees are valid for all Signals, not just messages. The spec lists the following signals
I know Rickard Green has made the semantics for Ports more clear in R16 because ports will be asynchronous and thus you need to know what guarantees you have about them in your program. This question, about messaging, is the same. In a language like Java or Go, you have a "memory model" which describes the semantics of passing messages and a "happens before" relation. It definitely makes sense to have the same for Erlang, so programmers know what relation they can rely on and what they can't.
Jesper Louis Andersen
Erlang Solutions Ltd., Copenhagen
Rickard Green
>
> The question is as following: Assume we have processes A and B which
> are linked. Process's A flag trap_exit is set to true. Let B process
> send a msg to A and then exit:
>
> PidA ! 'msg',
> exit(reason).
>
> What I wanna know if we can be shure that the process A will receive
> 'msg' and only after It {'EXIT', Pid, reason} will come ?
> Can
> we predict the ordering of msgs? I can't found any proofs in
> documentation, but I guess that it will work that way, but I need some
> proofs. Don't want to have race condition here.
>
following chapter will be part of the ERTS User's guide.
Cut from ERTS-5.10 User's Guide:
>
> 1 Communication in Erlang
>
> Communication in Erlang is conceptually performed using asynchronous signaling. All different executing entities such as processes, and ports communicate via asynchronous signals. The most commonly used signal is a message. Other common signals are exit, link, unlink, monitor, demonitor signals.
>
> 1.1 Passing of Signals
>
> The amount of time that passes between a signal being sent and the arrival of the signal at the destination is unspecified but positive. If the receiver has terminated, the signal will not arrive, but it is possible that it triggers another signal. For example, a link signal sent to a non-existing process will trigger an exit signal which will be sent back to where the link signal originated from. When communicating over the distribution, signals may be lost if the distribution channel goes down.
>
> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2.
>
> 1.2 Synchronous Communication
>
> Some communication is synchronous. If broken down into pieces, a synchronous communication operation, consists of two asynchronous signals. One request signal and one reply signal. An example of such a synchronous communication is a call to process_info/2 when the first argument is not self(). The caller will send an asynchronous signal requesting information, and will then wait for the reply signal containing the requested information. When the request signal reaches its destination the destination process replies with the requested information.
>
> 1.3 Implementation
>
> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above.
>
> By inspecting the implementation you might notice that some specific signal actually gives a stricter guarantee than described above. It is of vital importance that such knowledge about the implementation is *not* used by Erlang code, since the implementation might change at any time without prior notice.
>
> Some example of major implementation changes:
>
> As of ERTS version 5.5.2 exit signals to processes are truly asynchronously delivered.
> As of ERTS version 5.10 all signals from processes to ports are truly asynchronously delivered.
Richard Carlsson wrote:
> The only place I seem to find this actually described is in the old
> (never finished) Standard Erlang Specification Draft by Barklund and
> Virding. In brief, Thomas is right: with regards to propagation and
> order, exit messages are handled like regular messages. In fact, both
> are instances of what the spec calls Signals, and the ordering
> guarantees are valid for all Signals, not just messages.
Barklund/Virding spec <http://www.erlang.org/download/erl_spec47.ps.gz>.
Unfortunately the spec was never completed. I find the spec really
valuable. Hopefully, we will some day find the time to update and finish
it. Perhaps we could get some help from the original authors; hint hint :-)
Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB.
Richard O'Keefe
On 29/01/2013, at 10:34 AM, Rickard Green wrote:
>> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2.
>> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above.
The English spelling of behaviour is usual in Erlang.
Rickard Green
>
> On 29/01/2013, at 10:34 AM, Rickard Green wrote:
>>> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2.
>
> s/if A send/if A sends/
>>>
>>> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above.
>
> Unless you are deliberately using American speling, s/behavior/behaviour/.
> The English spelling of behaviour is usual in Erlang.
>
>
R16B.
Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB.
Ignas Vyšniauskas
> The only signal ordering guarantee given is the following. If an
> entity sends multiple signals to the same destination entity, the
> order will be preserved. That is, if A send a signal S1 to B, and
> later sends the signal S2 to B, S1 is guaranteed not to arrive after
> S2.
But this is true only for single-node semantics/settings, correct?
At least I this paper[1] by Koen Claessen and Hans Svensson claims that:
> In Fredlund’s semantics the delivery of a message is instantaneous,
> meaning that all messages are delivered in exactly the order they are
> sent. Now, this is actually true for processes running on the same
> node, due to how the Erlang runtime system is implemented. It is,
> however, not true in general for a concurrency oriented programming
> language, and specifically not in a distributed setting with several
> different Erlang nodes.
In general, they have a similar example to the one described in this
thread where problems with the exit signal appear in Chapter 5 and conclude:
> After Fredlund proposed his single-node semantics, it was at least
> thought ”morally OK” to use this semantics to reason about and model
> distributed systems. However, messages actually can and do
> arrive in different orders in a distributed setting as compared to a
> local setting. A simple experiment involving 3 nodes already shows
> this, even when the nodes are implemented as 3 run-time systems
> running on the same workstation! Moreover, we discovered that the
> above was not merely a theoretical anomaly, but an actual problem
> with a real-life implementation. Along the same lines, many Erlang
> developers think it morally OK to test their distributed system on a
> single node. For the same reasons as mentioned above, errors might
> slip through.
There's also a more recent one[2] by Hans Svensson.
So I guess the moral is that it's not all so simple and nice when you
"really" start distributing and it's not a good idea to make strong
assumptions even about the tiniest details.
Regards,
Ignas
[1]: "A Semantics for Distributed Erlang", 2005:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.9412
[2]: "A more accurate semantics for distributed Erlang", 2007:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1723
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1723>
Richard Carlsson
> On 01/28/2013 10:34 PM, Rickard Green wrote:
>> The only signal ordering guarantee given is the following. If an
>> entity sends multiple signals to the same destination entity, the
>> order will be preserved. That is, if A send a signal S1 to B, and
>> later sends the signal S2 to B, S1 is guaranteed not to arrive after
>> S2.
>
> But this is true only for single-node semantics/settings, correct?
>
> At least I this paper[1] by Koen Claessen and Hans Svensson claims that:
>
>> In Fredlund’s semantics the delivery of a message is instantaneous,
>> meaning that all messages are delivered in exactly the order they are
>> sent. Now, this is actually true for processes running on the same
>> node, due to how the Erlang runtime system is implemented. It is,
>> however, not true in general for a concurrency oriented programming
>> language, and specifically not in a distributed setting with several
>> different Erlang nodes.
These are different things. The delivery order of signals between two
*specific* processes is always guaranteed, even in a distributed
setting. Even if process A is on node 1 and process B is on node 2, it's
easy to preserve the order. What Fredlund is talking about is the
message order over all sends in the system. They do not model the time
it may take in a distributed system for a message to be transferred from
the sender to the mailbox of the receiver. Within a single node, it
*used to* be the case that this operation was atomic. However, in a
modern Erlang node on a multicore machine, there may be several sends
being performed by different scheduler threads in true concurrent
fashion, so the atomicity assumption is fundamentally broken.
> In general, they have a similar example to the one described in this
> thread where problems with the exit signal appear in Chapter 5 and conclude:
>
>> After Fredlund proposed his single-node semantics, it was at least
>> thought ”morally OK” to use this semantics to reason about and model
>> distributed systems. However, messages actually can and do
>> arrive in different orders in a distributed setting as compared to a
>> local setting. A simple experiment involving 3 nodes already shows
>> this, even when the nodes are implemented as 3 run-time systems
>> running on the same workstation! Moreover, we discovered that the
>> above was not merely a theoretical anomaly, but an actual problem
>> with a real-life implementation. Along the same lines, many Erlang
>> developers think it morally OK to test their distributed system on a
>> single node. For the same reasons as mentioned above, errors might
>> slip through.
>
> There's also a more recent one[2] by Hans Svensson.
>
> So I guess the moral is that it's not all so simple and nice when you
> "really" start distributing and it's not a good idea to make strong
> assumptions even about the tiniest details.
No, the ordering guarantees exist and can be relied on. You just can't
assume a total order, even if that assumption makes your model easier to
reason about. Your results won't be applicable on the real world.
/Richard
Ignas Vyšniauskas
> These are different things. The delivery order of signals between
> two *specific* processes is always guaranteed, even in a distributed
> setting. Even if process A is on node 1 and process B is on node 2,
> it's easy to preserve the order. What Fredlund is talking about is
> the message order over all sends in the system.
Ignas
David Mercer
> Unless you are deliberately using American speling, s/behavior/behaviour/.
> The English spelling of behaviour is usual in Erlang.
:-)
Cheers,
DBM
Richard O'Keefe
On 30/01/2013, at 3:36 AM, David Mercer wrote:
> On Monday, January 28, 2013, Richard O'Keefe wrote:
>
>> Unless you are deliberately using American speling, s/behavior/behaviour/.
>> The English spelling of behaviour is usual in Erlang.
>
> So the guy who wants to be able to write Erlang in Maori wants to prohibit us from writing in American English.
You *quoted* the part "Unless you are deliberately using American speling".
Did you *read* it?
Where does it say "don't write in American"?
(As opposed to say Microsoft Word, which does its level best to stamp out
non-American varieties of English.)
The point at issue is not dialect X vs dialect Y but *consistency*.
To quote another chunk of Erlang documentation,
Behaviour Module Attribute
It is possible to specify that the module is the callback
module for a behaviour:
-behaviour(Behaviour).
The atom Behaviour gives the name of the behaviour, which
can be a user defined behaviour or one of the OTP standard
behaviours gen_server, gen_fsm, gen_event or supervisor.
The spelling behavior is also accepted.
Read more about behaviours and callback modules in OTP Design
Principles.
Given _that_, was it really so unlikely that the omission of the
'u' from the word was an _unintential_ typo?
There may well be other places where the word has been differently
spelled. My point is not to follow this spelling or that speling
but to pick one and stick to it.
And what I said in an earlier thread was that I wanted my *students*
to be able to write Erlang in Māori because it is a policy of this
University that students should be allowed to perform assessment work
in Māori.