Re: Pi-Calculus Model question.

Ricky,

when you say can they share the same channel do you mean can they do 
this at the same time (i.e. multicast or pub/sub) or do you mean can 
they share the same channel one after the other?

Cheers

Steve T

On Monday, April 14, 2003, at 06:55  pm, Ricky Ho wrote:

>
> Assaf, thanks a lot for elaboration.  I have some more questions 
> embedded.
>
>
> At 09:38 AM 4/14/2003 -0700, Assaf Arkin wrote:
>
>> Ricky Ho wrote:
>>
>>> Assaf, thanks for your detail explanation of the Pi-C model.  I have 
>>> some following questions.
>>>
>>> 1) Can a channel have more than one listening process ?
>>
>> Receiving a message over a channel is something an action does. So 
>> you may want to have different actions listening to the same channel 
>> at different points in times.
>
> I'm thinking the 3-party scenario  P | Q | R.  Can there be two 
> parties listening on the same channel ?
>
> By reading the example, I observe that
> 1) All "send" operation can be reduced
> 2) An "receive" operation can be reduced if it can find a concurrent 
> matched "send" operation.
>
> So if there are multiple "receive" from more than one party, which one 
> will be received ?  I expect multiple channel listening (at the same 
> time) should NOT be allowed.  But I want to confirm with you the 
> actual answer.
>
>
>> If you are talking about broadcast, then you would model it 
>> differently by either talking to distinct listeners over different 
>> channels, or expressing infinite number of indistinct listeners using 
>> one channel.
>
> Lets introduce two more roles, "Airplane Shipper" and "Truck Shipper", 
> each has its own process flow.
>
> There are two cases here.
>
> 1) Queue scenario
> The seller send a "shipment request" to a channel.  Can both Shippers 
> listening on this same channel but only one of them will successfully 
> receive it ?  Lets say the seller doesn't care and both shippers are 
> competing to get the shipment request.
>
> 2) Broadcast scenario
> The seller send a "shipment request" to a channel.  Can both Shippers 
> listening on this same channel and both receive it ?
>
> In this example, since only one shipper will get the shipment request 
> while the other one will just wait but never gets it.  Is the 
> composition process still reducible to 0 | 0 | 0 | 0 ?
>
>
>> But these are all formalisms of a lower-level language. A lower-level 
>> language may take a multicast protocol like IP multicast and express 
>> it in terms of distinct channels, e.g. representing MAC addresses. In 
>> a higher-level language you'll simplify that by having a multicast 
>> capability which yields to that formalism but is easier to work with.
>>
>>> 2) How to do reduction when "condition" steps are involved ?  Are 
>>> the following reducible ?
>>>
>>> Process placeorder
>>>   Send order
>>>   Receive orderResponse
>>>
>>> Process acceptOrder
>>>   Receive order
>>>   switch
>>>     case conditionX
>>>       Send orderResponse
>>>     default
>>>       Send errorResponse
>>
>> Nope. You end up at a point where one send can be reduced with one 
>> receive. But you have another send that can happen and nothing to 
>> reduce it with.
>
> Does it match now if I change to ..
>
> Process placeorder
>   Send order
>   Choice
>     Case 1
>       Receive orderResponse
>     Case 2
>       Receive errorResponse
>
> Process acceptOrder
>   Receive order
>   switch
>     case conditionX
>       Send orderResponse
>     default
>       Send errorResponse
>
> If so, how does the "choice/receive" match with "switch/send" ?
>
>
>>> 3) So far, each steps within a process is sequential.  Can a process 
>>> have multiple steps in parallel ?  If so, can you give me an example 
>>> ?  And how reduction will be done in this case ?
>>
>> Do you mean multiple different steps or multiple instances of the 
>> same step?
>>
>> If you mean different steps than I've already shown that. Remember 
>> that nothing interesting happens on its own, all the interesting 
>> things happen concurrently. To receive a message someone also have to 
>> send it. So the first example I gave contained two things that happen 
>> in parallel and you can extend it to 3, 4, etc. However complex it 
>> is, you can easily express it.
>
> I mean multiple different steps but from the same process (party).  
> For example, lets say the seller in parallel send one shipment request 
> to the airplane shipper and another shipment request to the truck 
> shipper.  And then he wait for both respond and then select one with a 
> cheaper price before proceed to next step.  How do you represent the 
> "synchronization" after two parallel steps ?
>
>
>> If you mean the same step occuring n times in parallel, then #4 gives 
>> an example for that.
>
> #4 shows the same step occuring n times "sequentially" but not "in 
> parallel".  Right ?
>
> Rgds, Ricky
>
>
>> As for showing the reduction, this is where pi-c becomes more 
>> complicated than elementary school algebra and you'll have to start 
>> looking into congruence, simulation, bi-simulation, etc. I'm not 
>> mathematically inclined, so I can't give you a much better 
>> explanation that you can find in Milner's book.
>>
>>>
>>> 4) Can you give me a loop example ?  I vaguely recall you can use a 
>>> recursive definition to achieve that.
>>
>> Reflexive.
>>
>> until = send:start | ! ( receive:start.doSomething.(send:start[x=y]0) 
>> )
>>
>> The ! (bang) precedes a process that can happen n times (0 to 
>> infinity) whenever it's guard is able to receive a message. So !P = 
>> !P | P = !P | P | P = P | P | P ... It's also called replication and 
>> represents the ability to do the same thing n times. For example, a 
>> Web server that receives an HTTP request and sends back a response 
>> does the same thing n times.
>>
>> The [x=y] is some shorthand for evaluating a condition. If the 
>> condition is false you do the process on the left, if it's true you 
>> do the process on the right (kind of like if ... else ... ).
>>
>> So in this case you have a loop that is performed at least once, if 
>> x=y it ends, and if x!=y it repeats, essentially an until loop, and 
>> it repeats itself without recursion.
>>
>> arkin
>>
>>>
>>> Best regards,
>>> Ricky
>>
>
> This email is confidential and may be protected by legal privilege. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Monday, 14 April 2003 16:28:18 UTC