What you are doing by using a synchronous sending mechanism as described above AND letting both P and Q send requests to each other is effectively implementing dead lock. Because messages will cross, sooner or later, and if both P and Q can send requests to each other and these requests cross in between you have a dead lock. You should consider what you really want to achieve with synchronous message passing (or rather synchronous requests, there are no such thing as synchronous message passing, it is one way only).

Synchronous requests can be desirable in certain situations, but almost never in a P <-> Q relation. Then you would also need atomic synchronous message requests. That could maybe be achieved but very unlikely what you really want.

<br><br>Cheers!<br>Adam<br><br><div><span class="gmail_quote">On 10/3/07, <b class="gmail_sendername">ZeD</b> <<a href="mailto:vito.detullio@gmail.com">vito.detullio@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Richard Carlsson wrote: >> synchro(P, {do, Q, {ask, P}}). > It seems that you are not talking about normal synchronous communication, > but rather a form of nested request/reply. In synchronous message passing,

<br>> if P is waiting for a reply from Q then he is by definition blocked and<br>> cannot answer the query from Q. Your implementation in synchro2 is<br>> correct, but synchronous communication is not what you need for this

<br>> problem. You have to rethink what f does.<br><br>mmm<br><br>maybe I made a wrong example, or maybe you are right (effectively using<br>asinchronous communications I can have a reply)... let me change the<br>question:

if a process P want to make a synchronous call to Q, then it send a message and waits for a reply. What's appened when another process, R (just for make and example) send a message to P 'before' the Q reply?

<br>In particular, what if Q first send another message to P, then waits for the<br>reply, and only after all this, send the reply to the original message to<br>P?<br><br>Oh, and just to know, let's say P was described by the function f(), which

<br>have a receive; now P want to talk to Q, then now the behavior of P is<br>described by synchro2(), wich also have a receive. Let's say P finally had<br>a reply, so the control came back to f(). What append to messages not

<br>matched by synchro2()? they became automatically "receveived" by f()? They<br>get lost?<br><br>--<br>Under construction<br><br>_______________________________________________<br>erlang-questions mailing list

<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>

</div><br>