mpc

Table of Contents

1 Semantics of Ports

We add a mutable store. So we have three kinds of stores:

  1. Single Assignment Store: S
  2. Trigger Store: T
  3. Mutable Store: M

M contains pairs of the form X:Y where X and Y are variables in the Single Assignment Store.

The mutable store is initially empty.

Invariant: X is always bound to a name value that represents a port and Y is unbound. Names are unique, unforgeable constants.

Execution State is now (MST, S, T, M).

1.1 NewPort

({NewPort <s> <p>}, E)

does the following:

  1. Create a fresh port name n.
  2. Bind E(<p>) and n in the single assignment store.
  3. If the binding is successful, then (1) Add the pair E(<s>) : E(<s>) to the mutable store M.
  4. Else (1) Raise an error condition.

1.2 Send Operation

({Send <p> <y>), E)

  1. If E(<p>) is determined (1) Uf E(<p>) is not bound to a port, then raise error (2) If the mutable store contains E(<p>):z
    1. Create a new variable z' in the store
    2. Update the mutable store to be E(<p>):z'
    3. Create a new list pair E(<y>)|z' and bind z with it in the single assignment store.
  2. Else, suspend execution.

In a correct port, the end of the stream should be read-only. We have not implemented this. This can be implemented with "Secure ADT"s.

1.3 Memory Management

  1. Extend the definition of reachability. If x:y is in the mutable store, and x is reachable, then y is reachable as well.
  2. If the port variable x becomes unreachable, and the mutable store contains x:y, then y becomes unreachable as well.

2 Port Objects

A combination of one or more ports and a stream object.

Extends stream objects with many-to-one communication. Also, port objects can be embedded inside data structures.

Similar ideas in other languages: Agent Erlang Process Active Object

Message Passing Model: Program consists of a graph of interacting port objects.

declare P1 P2 ... Pn
local S1 S2 ... Sn in
  {NewPort S1 P1}
  {NewPort S2 P2}
  ...
  {NewPort Sn Pn}
  thread {RecrsveProc S1 ... Sn} end
end

RecrsveProc is a recursive procedure that reads the port streams and performs some actions for each message received.

Sending a message to a port objects: Send a message to any of the streams.

declare Port
local Stream in
   {NewPort Stream Port}
   thread for M in Stream do {Browse M} end end
end
% Only Port is visible outside
thread
   {Send Port hello}
   {Delay 1000}
   {Send Port world}
end
thread
   {Send Port hi}
end

2.1 Port Object abstraction

If there is no internal state, then the new port is simple.

fun {NewPortObject2 P}
Sin in
  thread
    for Msg in Sin do
      {P Msg}
    end
  end
  {NewPort Sin}
end

However, we can also consider ports which have an internal state, similar to that in the case of stream objects.

fun {NewPortObject InitState F}
Sin Sout in
  thread {FoldL Sin F InitState Sout}
  {NewPort Sin}
end

Using this, we can program simple message passing protocol.


e.g. from the text

3 players tossing a ball to each other. Each recepient tosses the ball to one of the other two, chosen at random.

Each player is a stateless port object.

Code: Players.oz


2.2 Reasoning with Port Objects

Proving a program correct consists of two parts.

  1. Show that the port object is correct. Each port object defines a data abstraction. The abstraction should have an invariant assertion. Since the inside of a port is declarative, we can use the techniques for declarative programs.

    Each port object has a single thread. Hence it's operations are executed sequentially. Hence mathematical induction provides a way to assert invariants.

    • When the port object is first created, the invariant is satisfied.
    • If the assertion is satisfied before a message is handled, then the assertion is satisfied after it is handled.
  2. Show that the program using the port objects is correct. This involves interacting ports. We have to determine the possible sequences of messages that each port can receive. First, we classify the events - message sends, message receives, internal state changes.

    Then we can consider the program as a state transition system. Reasoning about the correctness of such transition systems is complicated.


3 Simple Message Protocols

3.1 RMI

|\ |       Method is port's message-handling procedure.
| \|       A client sends a request to a server and waits for a reply.
|  |
|  |       ---------Server---------
| /|       proc {ServerProcedure Msg}
|/ |         case Msg
|  |           of append(X Y Z) then {Append X Y Z}
|\ |         end
| \|       end
|  |       Server = {NewPort2 ServerProcedure}
| /|       ------------------------
|/ |
|  |       ---------Client---------
C  S       proc {ClientProcedure Msg}
             case Msg
               of work(X Y Z R) then
                 local W in
                   {Send Server append(X Y W)}
                   {Wait W}
                   {Send Server append(W Z R)}
                 end
               end
             end
           end
           Client = {NewPort2 ClientProcedure}
           declare R
           {Browse {Send Client work([1 2] [3] [4] R)}
           -------------------------

The client refers directly to the server, but not vice versa.

This is a synchronous call.

3.2 Asynchronous RMI

|     |
|\    |       The client proceeds immediately after sending the request, 
| \   |       without waiting  for the server response.
|  \  |
|\  \ |
| \  \|
|  \  |
|   \/|
|   /\|
|  /  |
| /  /|
|/  / |
|  /  |
| /   |
|/    |
|     |
C     S

3.3 RMI with callback (using threads)


4 Using the Message Passing Model directly

4.1 Port Objects that share one thread

TBD

4.2 A thread abstraction with termination detection

TBD

4.3 Eliminating Sequential Dependencies

proc {ConcFilter L F ?L2}
   Send
in
   {NewPort L2 Send}
   {Barrier
       {Map L
            fun {$ X}
               proc {$}
                   if {F X} then {Send X} end
               end
            end}}
end

5 Semantics of Erlang Receive

Erlang is a concurrent, functional programming language developed by Ericsson. It supports efficient threading, fault tolerance, and "hot code replacement". The computation model has the following features.

The computational model consists of communicating entities called "processes". Each process has a port, and a mailbox.

  1. A Functional core: Erlang is a dynamically typed, strict language. (Arguments are evaluated eagerly.) Each process has a port object defined by a recursive function. A process is spawned by specifying the initial function to execute.
  2. Message-passing extension. Processes communicate by sending messages to other processes, asynchronously. The messages are delivered in FIFO order. Messages can contain any value, including functions. Each process has a unique process identifier, PID.

    Message receiving can be either blocking or non-blocking. The reception works using pattern-matching. Messages can be removed out-of-order, without removing the others in the mailbox.

Processes are independent by default (what other model is there?). This implies that messages are always copied from one process to another, never shared. Independence is better for reliability.

We are concerned only with these features of Erlang for the present. The complete language has features for distribution, fault-tolerance via linking of processes, and persistence.

-module (helloserver).
-export ([start/0, receiverloop/0]). % functions exported publicly,
                                     % other functions are 'private'.
                                     % foo/n denotes that foo is a
                                     % function with n arguments.

% spawn a process with the module helloserver, executing the function
% receiverloop. The argument list to receiverloop is empty.
start()->
   spawn(helloserver, receiverloop, []) 


receiverloop()->
   receive
       {From, hello}->          % Message format : {Pid, hello}
           From!hi,             % Send hi to process with Pid 'From'
           receiverloop()
   end.                                        

5.1 The receive operation

In this section, we will try to describe the semantics of the Erlang receive operation, in terms of equivalent Oz statements.


Date: 2012-10-16 13:05:41 India Standard Time

Author:

Org version 7.8.11 with Emacs version 24

Validate XHTML 1.0