General (not specific to LV/AF) Actor Theory

[lukepike]

Yes, I suppose you're right; wasn't thinking clearly. I'll have to do some research to see if there is a formalization. I probably wouldn't be able to understand it now, I haven't taken discrete math yet. Any recomendations on subjects to take to understand that pi calculus?.

[AristosQueue (NI)]

lukepike wrote:

Any recomendations on subjects to take to understand that pi calculus?.

I never encountered pi calculus in school. I assume you'd have to find a professor to ask about it specifically. I only encountered it by chance about two years ago.

[drjdpowell]

Another paper I found, a recent one by Hewwit.

[Daklu]

There must be some miscommunication or poor terminology going on.  Surely "an address" and "a message" are non-actor things in the model?   Anyway, why would "everything must be an actor" be an interesting or in any way useful prescription?  

I interpret "everything is an actor" to mean everything that has a concrete representation in the programming language.  As near as I can tell, messages don't have concrete representations in the actor model.  For example, in all the LV messaging systems I know about the act of creating a message and the act of sending a message are two distinct operations (though the operations may be abstracted away in the messaging system's source code.)  It appears to me as though they are one and the same in the actor model.  You cannot create a message without also sending it.  I imagine sending a message to another actor is done in exactly the same way as you would call a method on a local class.

It is possible to write LV code in which the syntax for sending a message to a remote actor is identical to the syntax of invoking method on a class.  Some of my earliest "slave loop" examples on Lava used that strategy.  While I like the idea, I ended up discarding it because the cost of using it exceeded the benefits I received by using it.  (It added significant time and complexity.)

However, while my original slave loop examples allow people to use an actor without having to know anything about the transport mechanism, programmers implementing an actor had to explicitly manage the messaging transports.  As I understand the actor model the messaging transport is not only undefined, it is irrelevant.  The messaging just happens.  How does it happen?  I have no idea.  Obviously it would have to be built on some sort of messaging infrastructure.  But as far as the programmers coding the actors are concerned it's automatic.

Encapsulation of state information (no by-ref sharing of data) is the most important thing; I think we all do that.

It may or may not be the most important thing--I can't say.  The problem is we're each putting our own interpretations of what the actor model means.  To some extent we're molding the definition to fit our implementations rather than the other way around.  I'm certainly not in a position to fairly evaluate the relative validity or merits of any of our interpretations.  Before I can even attempt to do that I need to understand what Hewitt means when he talks about actors.

But can you meaningfully define literally everything as an actor? The numbers 0 and 1, like in your lambda calculus example? The messages themselves? The Cosine function?

I'll say I believe it is theoretically possible to create an implementation where everything at the language's level of abstraction is an actor, though I doubt it is practical in LV and may not even be possible.  Numbers, strings, etc. can be modelled as actors.  The Cosine function?  Sure.  In the video he specifically mentioned the factorial function as being an actor.  Messages?  I'm not sure messages exist as an independent entity in Hewitt's vision, but if they did I don't see a problem with modelling them as actors.  If you can model it as a class, you can model it as an actor.  (That my current line of thought anyway.)

Another paper I found, a recent one by Hewwit.

Thanks for the link.  That's the paper I was referring to in post #7, but I had lost the link and couldn't find it again.  The second property I was referring to can be found on page 3 of the paper:  "Message passing has the same overhead as looping and procedure calling."  He goes on to say,

"Because message passing is taken as fundamental in the Actor model, there cannot be any inherent overhead, e.g., any requirement for buffers, pipes, queues, classes, channels, etc. Prior to the Actor model, concurrency was defined in low level machine terms.

"It certainly is the case that implementations of the Actor model typically make use of these hardware capabilities. However, there is no reason that the model could not be implemented directly in hardware without exposing any hardware threads, locks, queues, channels, tasks, etc. Also, there is no necessary relationship between the number of Actors and the number threads, locks, tasks, queues, etc. that might be in use. Implementations of the Actor model are free to make use of threads, locks, tasks, queues, global assignment, coherent memory, transactional memory, cores, etc. in any way that is compatible with the laws for Actors [Baker and Hewitt 1977]."

[AristosQueue (NI)]

So, a bit more info... Hewitt's model is basically the same as what might be termed asynchronous dataflow.

Take your average string of nodes in LabVIEW, say three Increment primitives wired in a row. Wire an array to the first one and hit the run button. What happens? The first one returns an array of incremented values, then the next one returns, then the final one returns.

Now, in the asynch model, the first one would increment the first element of the array and pass it out. Then, the first two increment primitives would run at the same time, the first one operating on the second element of the array, and the second one operating on the first element of the array.

Now make it a full actor model: the first one might get through half the array before the second one gets going. Then the second one might pull head. The third meanwhile is plodding along, but speeds up once the first two are done and there's room on the CPU. In this sense, the cosine function or any of the other nodes becomes an actor. It fires when its inputs are available, even if the upstream node is still working on stuff.

And thus all functions are actors acting on messages passed between them. If you take LabVIEW and you remove all the loops, then you would have the right model: the first node in a chain would just keep producing values until it encountered some sentinel value, and then it would just stop producing any further values. We see this kind of setup when programming LV on FPGA with pipelining.

[Daklu]

AristosQueue wrote:

Hewitt's model is basically the same as what might be termed asynchronous dataflow.

I don't quite agree with you... yet.  I think it's possible to implement asynchronous dataflow using actors, but it's also possible to implement synchronous dataflow.  It all depends on how the actors are written.

Assume our hypothetical Increment actor implements an IncArray message.  If IncArray is written to return each element of the array as it is incremented we'll have asynchronous dataflow.  However, it seems equally acceptable to write the actor so it waits until the entire array is incremented before sending a return message.  I think the decision to pipeline data processing is made independently of the actor model.

[Edit]

In fact, there are situations where we specifically may not want data pipelining.  Consider calculating the RMS of an array of values.  If the Square actor forwarded the square of each element as it is calculated, how is the Mean actor going to know when it has all the data?  Should the Square actor send an "I'm done" message?   That doesn't make any sense to me.  The Mean actor could keep a running total and count of the values it has received and return the new mean value every time it receives a new value, but then it also needs some sort of Reset message.

[AristosQueue (NI)]

Daklu wrote:

In fact, there are situations where we specifically may not want data pipelining.  Consider calculating the RMS of an array of values.  If the Square actor forwarded the square of each element as it is calculated, how is the Mean actor going to know when it has all the data?  Should the Square actor send an "I'm done" message?   That doesn't make any sense to me.  The Mean actor could keep a running total and count of the values it has received and return the new mean value every time it receives a new value, but then it also needs some sort of Reset message.

You're jumping up to too high a level. How would you have written the Mean.vi in the first place if you can only drop actors on the block diagram? You can't loop. There are no loops. Only actors that send messages. So, yeah, to write a loop that iterates over an array, someone is going to have to be an actor that knows how to send an "End of data" message. Then that would be used in the Mean.vi.

If you only have actors, you have to start small and build up. You should be able to build the macroscopic synchronous AND macroscopic asynchronous dataflow models out of the microscopic actor parts, and that microscopic part looks a lot like the "single element buffer between asynch dataflow actors".

[Daklu]

AristosQueue wrote:

...out of the microscopic actor parts...

Right, I see what you're saying.  My suggestion to have the Mean actor keep a running total and count internally doesn't work--it might receive a "Reset" message from another actor and throw off the calculations.  And the Mean actor doesn't work alone; it sends messages to the Add and Divide actors.  It also can't block while waiting for return messages from Add and Divide since the return message can take an arbitrarily long time.  I guess the state of the complete calculation needs to be carried through with all the messages...

Wow, this gets complicated quickly.  Breaking down an RMS actor feels similar to functional programming, except functions return to the same point in the calling function when they complete.  Actor do not.