Concurrent computing and the Actor Model, seek for suggestions

Concurrent computing and the Actor Model, seek for suggestions

Post by fulimi » Thu, 30 Nov 2006 23:21:19


ello,

I implemented a scripting language, Dao, which is released as 1.0-beta
version some days ago. Dao supports concurrent programming by providing
native thread, mutex and semahpore types; it also provides coroutines
as an additional concurrent facility. I believe concurrent computing
will become more and more important in the future, so I would like to
add more concurrent programming ability to this new language.

The first thing I could do is to add to Dao some new language
constructs such as "parbegin ... end", to allow statements or blocks in
their between being executed parallelly. That is essentially the same
as using threading library, and do not simplify concurrent programming.
It may be useful for parallel numerical computing, but not suitable to
construct complex concurrent system. So I looked around for high level
concurrent computing models, and found the Actor Model, which seems to
be most attracting to me. After reading something about this model, I
feel I got some ideas on how to add this concurrent model to Dao. I
have list those rough ideas below to seek suggestions from you.

I should admit I am extremely new to this field (actually got to know
this field since yesterday;-) ), so the first thing I would like to
know is that, is there any flaw in the ideas I list below?

Secondly, is it really necessary to add language constructs into Dao
for such type of concurrent computing (such as statement named "send
..." ect.)? Since I found these ideas could be implemented as a package
in Dao language itself using the native threading library. But adding
language constructs may render this new langauge more attractive, this
is one factor I will take into consideration;-)

Thanks a lot!

Limin


================
The Rough Ideas:
================

Features in the Dao language that are useful for implementing
concurrent system (using threads within single OS process) based on
Actor Model:

1. native threading;
2. function overloading by parameters;
3. callable class instance with "_CALL" methods that overload function
call operator "(...)".


----------
Actors:
----------

Actors should be callable objects:

functions, function closures, class instance with "_CALL()" methods,
wrapped C functions, wrapped C types with "_CALL()" methods.

----------
Messages:
----------

Any Dao data types.

-------------------
Message sending:
-------------------
send( mode, actor, msgObj1, msgObj2, ... )

mode: can be asynchronous or synchronous.
For real time system it can also be used to indicate that the actor
must respond to
the messages immediately, bypassing the underlying message queue.

actor: the receiver, identified by memory address within the same OS
process.

msgObj1, msgObj2, ...: the message;

--------------------------
Re-acting to message:
--------------------------

In response to message, actors are called:
actor( msgObj1, msgObj2, ... );

If the actor is an overloaded function, the function with parameter
types matching to message objects are called. If the actor is a class
instance with overloaded "_CALL" methods, similarly the one with
matching parameters is called. In this way, different behaviors of the
same actor can be implemented as different functions or methods, and
the virtual machine of Dao will choose the right one based on the types
of the message objects.

Note: the drawback of this, exception handling is not yet imple
 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by Arthur J. » Fri, 01 Dec 2006 02:29:01


ISTR reviewing your documentation a while back, and I didn't see
anything about coroutines there yet. That would be a nice thing to add
documentation on, because IMLE that's one feature most languages don't
have.


Surely (1) that's something the compiler can figure out better than
a human programmer anyway; and (2) a linear, nested "parbegin...end"
syntax seems totally the wrong way to represent parallelism in code.
I haven't investigated compiler support for parallelism myself, but
it seems to me that you could (and should?) get by with just an optional
declaration at the top of each program or block

Threads: 5

indicating that the compiler should try to schedule instructions in,
say, 5 parallel threads.
I don't know what would be the best way to get the compiler to deal
automatically with algorithms suggesting N parallel threads, where N
is a function of the user's input, except by making the programmer do
all the work himself with thread-library primitives. But I'm sure some
functional-programming language has tackled this problem already.

[re: Actor Model]

Since I'm a C person, I'd do it with a library of functions. Different
languages put the library--keyword barrier at different places, of course.

If you're going to go with keywords, though, it seems to me that you're
really looking for a syntax more like

retval = foo(arg1, arg2) asynch;
retval2 = bar(arg1, arg2) asynch hurry;

rather than

retval = send(ASYNCH, foo, arg1, arg2);
retval2 = send(ASYNCH | HURRY, bar, arg1, arg2);

That is, I'd use "attribute" keywords to indicate when I wanted a
procedure call to act funny, rather than using a whole different syntax.
The "send" syntax has the advantage of alerting the reader that something
strange is about to happen; but maybe you can design the language cleverly
enough that asynchronous function calls /aren't/ so strange anymore, in
which case you don't want to make them look strange! :)

my $.02,
-Arthur

 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by fulimi » Fri, 01 Dec 2006 20:29:00

Arthur J. O'Dwyer

There is a little piece text for coroutines, not in the quick guide,
but in library reference:
http://www.xdao.org/daoweb.dao?page=libref#COROUTINE

The explaination is a little bit obscured. But the coroutine in Dao is
almost identical to that in Lua:
http://www.lua.org/manual/5.1/manual.html#5.2


Parallelizing instruction by instruction is a very complicated task for
compilers, because to determine the dependency among instructions
requires a thorough analysis of the data flow and control flow. That
would be too much, if I want to keep Dao and its interpreter as light
as possible.

The first time I saw that kind of syntax (it was "parbegin ... parend")
is from the book of Filman and Friedman about Coordinated Computing. In
the same book, there is a similar syntax,

parbegin:
process1:
begin:
...
end
process2:
begin:
...
end
parend

in this way, parallization only occurs between blocks process1 and
process2. The programmer will be responsible to decide how many threads
or processes to be used, and also responsible to synchronize the use of
shared variables. This syntax is just a syntax sugar for using thread
library, only to avoid explicitly defining two functions and creating
two threads. So I am not sure if I will support this in Dao (most
likely not).



Could you point me to some reference for such functional-programming
language? I wasn't aware of this.


You are right. It is important to alert the reader to the concurrent
behavior of the code. But the syntax you suggested may obscure the
meaning of the Actor-Model, but if you want to hide the Actor-Model,
then this syntax is very good, and looks cool;-). Maybe it is not
important to expose the Actor-Model to the programmer, do you also
think so?


There is some kind of Chinese proverb (influenced by Buddism) saying
something like this, $ (and many other things) is unreal, since people
do not bring it with them when they are born, nor can they take it with
them when they die. But, it is also real, people can (almost) not live
without it. So I chose $ as the imaginary part of a complex number for
fun:)

Limin

 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by Arthur J. » Sat, 02 Dec 2006 10:27:01

On Thu, 30 Nov 2006, fulimin wrote:

I think I get it. It looks natural enough to me.

[re hints to the optimizer for parallel computing]

I was assuming that "a thorough analysis of the data flow and control
flow" was a prerequisite for /any/ good compiler. :) If you want to
keep the compiler simple, then just don't support more than one thread
of execution!



I don't know of any research in the area; I'm just saying that I would
be very surprised if no such research existed. (In this case, "I'm sure"
is an idiom meaning "I really have no idea, but I would bet on it." ;)

[...]

I'm not the right person to ask. ;)

-Arthur
 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by fulimi » Tue, 05 Dec 2006 19:23:32

"Arthur J. O'Dwyer
"

I think it may depend on how you understand "data flow" and "thorough"
;)


I will look for it.


It doesn't matter:), I almost finished implementing it. I found I
really like this syntax, thank you for your suggestion.

Limin
 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by santos » Tue, 05 Dec 2006 23:44:33


I think Erlang is good example of a language with built-in support for
massive parallelism. Look it up on the web.
 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by fulimi » Wed, 06 Dec 2006 00:02:26

"santosh
"


I already had a look at it ;)
Its parallelization is exactly based on the Actor Model.

Limin
 
 
 

Concurrent computing and the Actor Model, seek for suggestions

Post by santos » Wed, 06 Dec 2006 00:09:36


[ ... ]

Why don't you also try comp.programming.threads and comp.parallel?