<div dir="ltr">On Thu, Jan 26, 2017 at 5:21 AM Dmitry Kakurin <<a href="mailto:dima_kakurin@hotmail.com">dima_kakurin@hotmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr" class="gmail_msg">
<div id="m_2671743969795203534divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr" class="gmail_msg">
<font class="gmail_msg" size="2" face="verdana,sans-serif" color="#3333FF">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.</font></div></div><div dir="ltr" class="gmail_msg"><div id="m_2671743969795203534divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr" class="gmail_msg"><font style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px" class="gmail_msg" face="Calibri,Arial,Helvetica,sans-serif"><br class="gmail_msg">
</font><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px" class="gmail_msg"></span><br class="gmail_msg"></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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:<br><br></div><div>Allocate a new message.<br></div><div>Try a CAS operation on the target mailbox.<br></div><div>If the CAS operation fails, delay the attempt to later due to contention on the target mailbox.<br><br></div><div>In this setting, there is no happens-before on '!', and thus messages may be reordered.<br><br></div><div>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.<br><br></div><div>My advice is to code for the rules of physics (causality). It tends to produce the best results in the long run. <br></div></div></div>