Erlang-Scala Challenge: The Actor program.

[rizzix]

Here's a simple challenge to get the folks of compsci.ca familiar with the Erlang-Scala style of concurrency.

Make a small little program that makes use of the Actor (message-passing) model. The program may either demonstrate this as a multi-threaded application or as a network application. You may use any language of choice that supports the Actor model.

What's expected:

• You are capable of learning a new concept on your own -- includes researching on the topic etc.
  
• You are capable of demonstrating your understanding of the topic through your code.
  
• You can think creatively. You can be innovative.

What's not expected:

• An explanation or understanding of the theory behind the actor-model.

The award: 600 bits for the best submission.

P.S: If the Actor model is not new to you, that's fine, you may still participate. However please do mention that when you submit your code.

[btiffin]

Sorry, I couldn't let this challenge go unanswered. This is not a true Erlang concurrency solution. It is a contrived Icon co-expression as coroutine example to see if I can prompt others here to try and pick up some Actor Model experience.

Yes I knew about the Actor Model before writing this simple (and as it is contrived - inefficient use of the powers of Icon). Icon co-expressions predate Erlang. So this can be used to implement an Actor Model, but it isn't natively Actor.

Icon:

############################################################### # # Demonstration of the Actor Model using Icon's co-expressions #  as coroutines.  (Well not really a full blown Actor Model) #  As stated in the Icon Book, this is not a tremendously #  effecient use of Icon features.  A simple generator would #  suffice for this contrived example. # ############################################################### global actor1, actor2 # main procedure, create the coroutines and start up the actors #   note; @actor is a shortcut equivalent of  &null @ actor procedure main()     local datum     &trace := -1     datum := [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]     #  summing using two co-expressions     write("create 1")     actor1 := create sumall()     write("create 2")     actor2 := create sumodd()     # for intial activation of co-expression, transmitted data is ignored     #   as there is nothing yet suspended to receive the data     #   we will use this opportunity to set the running (local) totals to zero     @actor2     # now to generate all the data and transmit to the sumall coroutine     every !datum @ actor1 end # the sum procedure; locals are captured in the co-expression procedure sumall()     local val, total     /total := 0     repeat {         # result transmitted is result of expression that called co-routine         val := @&main         # transmit odd values to the odd total coroutine         if val % 2 == 1 then val @ actor2         total +:= val         write("all total = ", total)     } end # the sumodd procedure procedure sumodd()     local odd, total     /total := 0     repeat {         odd := @actor1         total +:= odd         write("odd total = ", total)     } end

Which with trace on, produces;

code:

create 1 create 2 actor.icn    :   28  | main; co-expression_1 : &null @ co-expression_3 actor.icn    :   23  | sumodd() actor.icn    :   53  | | sumodd; co-expression_3 : &null @ co-expression_2 actor.icn    :   21  | | sumall() actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 1) @ co-expression_2 actor.icn    :   42  | | | sumall; co-expression_2 : 1 @ co-expression_3 odd total = 1 actor.icn    :   53  | | | sumodd; co-expression_3 : &null @ co-expression_2 all total = 1 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 2) @ co-expression_2 all total = 3 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 3) @ co-expression_2 actor.icn    :   42  | | | sumall; co-expression_2 : 3 @ co-expression_3 odd total = 4 actor.icn    :   53  | | | sumodd; co-expression_3 : &null @ co-expression_2 all total = 6 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 4) @ co-expression_2 all total = 10 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 5) @ co-expression_2 actor.icn    :   42  | | | sumall; co-expression_2 : 5 @ co-expression_3 odd total = 9 actor.icn    :   53  | | | sumodd; co-expression_3 : &null @ co-expression_2 all total = 15 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 6) @ co-expression_2 all total = 21 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 7) @ co-expression_2 actor.icn    :   42  | | | sumall; co-expression_2 : 7 @ co-expression_3 odd total = 16 actor.icn    :   53  | | | sumodd; co-expression_3 : &null @ co-expression_2 all total = 28 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 8) @ co-expression_2 all total = 36 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 9) @ co-expression_2 actor.icn    :   42  | | | sumall; co-expression_2 : 9 @ co-expression_3 odd total = 25 actor.icn    :   53  | | | sumodd; co-expression_3 : &null @ co-expression_2 all total = 45 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   31  | | | main; co-expression_1 : (variable = 10) @ co-expression_2 all total = 55 actor.icn    :   40  | | | sumall; co-expression_2 : &null @ co-expression_1 actor.icn    :   32  | | main failed

Posted solely to hopefully pique some curiosity in rizzix's challenge. The Actor Model of computing is a good thing to know. And FYI; this Icon program is NOT Actor as requested by rizzix (e.g. this is concurrent - but not threads as everyone here would probably know them as), this is more an old guy's attempt to prod.

Cheers

[apomb]

Seems as though multi-threaded apps, though necessary are just not as interest-inducing as one might hope.

I, for one wouldnt know the first thing about writing a multi-threaded application, let alone this actor model. However, i would be interested in seeing people's submissions.

[rizzix]

Its not that concurrent applications are not interesting. Its simply that most people do not know how to make use of concurrency, effectively.

The fact is you can write a lot of different kinds of useful programs without making use of any concurrency. The truth is, you haven't explored the possibilities of using concurrency in adequate detail.

[rizzix]

Here's a trivial example in Scala:

code:

import scala.actors._ object ActorTest extends Application {     object PING { override def toString = "PING" }     object PONG { override def toString = "PONG" }     object STOP { override def toString = "STOP" }         val pinger : Actor = new Actor {         def act = while (true) receive {             case PONG => { // upon receiving message PONG                 Console println PONG                 Thread sleep 1000                 ponger ! PING // Send message PING to actor ponger             }             case STOP => exit // Exits actor         }     };         val ponger : Actor = new Actor {         def act = while (true) receive {             case PING => {                 Console println PING                 Thread sleep 1000                 pinger ! PONG             }             case STOP => exit         }     }         // Start the actors     pinger.start     ponger.start         // The two actors are in receiving mode at this point. So fire a message to either one to get them to play.     pinger ! PONG     // We use a separte actor here to pause for 5s and then stop these two above,     // Note: We are NOT allowed to call Thread.sleep on the executing thread when using actors.     // Also note: Using the following alternative method of creating actors, implicitly starts them as well.     Actor actor {         Thread sleep 5000         pinger ! STOP         ponger ! STOP         exit     }     // All actors must `exit` for the program to terminate. }

Edit: Modified example to demonstrate terminating code.

[btiffin]

I was pretty lucky through most of my career. polyFORTH has had built in multi tasking since ... forever. A round robin multitasker where a task switch was as easy as one assembler instruction. SLEEP would effect the jump address of the task STATUS so that it jumped to the next task in sequence, WAKE would plop the address of the currently executing code field address (stashed away as the address following the SLEEP instruction or an interrupt vector. Pretty cool.

apomb; you may need to know this someday, but we encountered a tricky bug on our VAX/6000 series machines. It turns out the VIC (virtual instruction cache) was not good at detecting changes to the instruction steam so each SLEEP had to be followed by a REI instruction sequence. Two instructions; fake an interrupt and set the return address to the address following for the REI. Took us many days to track that one down. Once or twice a week a task would run past SLEEP. Freaked us out.

Everyone else; Get into rizzix's challenge if you can afford to. It'll be good for you.

Cheers

[apomb]

well btiffin, i dont exactly plan on becoming a programmer, im more interested in the hardware design side. However, that doesnt mean i will not continue learning certain programming paradigms.

I am always interested to see what the hardcore programmers come up with in terms of cutting edge code and this seems to be it. Now only if more people were interested in it, you might have something going.

[btiffin]

Ahh, well then; perhaps you'll be the one that figures out a smart cache that can detect modifications to the instruction stream.

And keeping in the spirit of the thread; concurrency is an area where performance can be critical and self modifying code space can be an excellent, simple and highly efficient way of task switching (then of course your design will not only have to detect the changes to cached memory, but also verify that the change isn't some badguy viral code - I'll leave that problem in your capable hands).

Cheers