Didàctica, Groovy

Programació concurrent + OOP ~ Actors Model: molt fàcil en Groovy

Fa temps que vaig descobrir Groovy (un llenguatge d’scripting sobre la JVM ideal per als que saben Java), i ara he trobat el complement ideal per a fer “pseudo-codi” (que es pot executar!) per a fer més fàcil l’estudi dels problemes de concurrència: GParallelizer. De fet, la cosa va més enllà, i es tracta d’una llibreria que facilita moltíssim la programació “en paral·lel” per aprofitar els nous multi-core…

Aquí va un petit exemple…

import org.gparallelizer.actors.pooledActors.AbstractPooledActor

class GameMaster extends AbstractPooledActor {
  int secretNum

  void afterStart() {
    secretNum = new Random().nextInt(10)
  }

  void act() {
    loop {
      react { int num ->
        if      ( num > secretNum )
          reply 'too large'
        else if ( num < secretNum )
          reply 'too small'
        else {
          reply 'you win'
          stop()
        }
      }
    }
  }
}

class Player extends AbstractPooledActor {
  String              name
  AbstractPooledActor server
  int                 myNum

  void act() {
    loop {
      myNum = new Random().nextInt(10)

      server.send myNum

      react {
        switch( it )
        {
          case 'too large':
            println "$name: $myNum was too large"; break
          case 'too small':
            println "$name: $myNum was too small"; break
          case 'you win':
            println "$name: I won $myNum"; stop(); break
        }
      }
    }
  }
}

final def master = new GameMaster()
final def player = new Player( name: 'Player', server: master )

master.start()
player.start()

Bé, sembla que aquest paradigma (que existeix des dels 70) va guanyant adeptes ara que estan de moda els multi-core: més en Groovy (1, 2) , Java, Scala, Python-Ruby (exemple chat), Erlang, .NET

L’exemple és petitó. La idea seria usar-lo per a les classes de concurrència. Els passos següents podrien ser:

– fer el jugador més “intel·ligent”: però no aporta res a les classes de Concurrència
– afegir més jugadors: servidor ha d’avisar a jugadors perdedors que la partida s’ha acabat
– servidor multi-actor: que el servidor estigui composat per més d’un actor, per tant afloren problemes d’accés concurrent al número secret…
– altres exemples en que hi hagi abraçada mortal donat el tipus de protocol…

vaja, que crec que permet “anar directament al gra” als problemes nous de Concurrència, deixant a una banda la dificultat habitual per a implementar-ho amb Java “pur”… com una mena de pseudo-codi (que es pot executar!). Un cop entesos i treballats els problemes, una darrera pràctica ja podria ser en Java “pur”.

He creat un fitxer comprimir http://namaste.maia.ub.es/actors2009-03-04.tar.gz, amb tot (groovy, llibreria actors i codi d’exemple), només cal descomprimir i executar…

; )

Anuncis

3 thoughts on “Programació concurrent + OOP ~ Actors Model: molt fàcil en Groovy”

  1. Mooola

    Imagino que en Groovy no hi threads i crees actors que es comuniquem amb missatges per repartir les tasques, no?
    Pots triar les característiques del canal de comunicació (blocking/non-blocking,….)

    J.

    1. Threads n’hi ha, perquè entre altres per sota tens a disposició tota la API de Java.

      Tan mateix, hi ha dos tipus d’Actors:

      GParallelizer comes with two types of actors, both of which have their uses. Thread-bound actors maintain their own thread of execution, whereas event-driven actors (as of the 0.6 release) share a common thread pool, from which they borrow threads whenever they must react to an event – typically a message sent to them.
      ” (http://code.google.com/p/gparallelizer/wiki/Actors)

      Respecte blocking/no_blocking, no ho trobo explícitament a la documentació (que de moment és molt “breu”), però hi ha la possibilitat d’establir un onTimeout() quan s’espera un missatge (acció que és bloquejant…).

      Vaig veure un exemple de xat (http://dramatis.mischance.net/repositories/entry/dramatis/examples/im) que també dóna molt de jo per aprendre (o podria complementar el del joc d’endevinar un número)…

      Sabeu d’altres exemples?

  2. Hello Jordi,

    I’m very glad my library can help you teach students important principles in a natural way. The examples you gave sound appealing to me. I’d love to be a student of your courses, I’m sure.
    I’ll be very happy to hear how the course goes.
    Regarding the professor’s concerns, there are two types of actors in GParallelizer – thread-bound and event-driven ones.

    1. The thread-bound actors each have their own thread, which blocks (optionally with a timeout) when calling receive() to obtain a message from an empty queue.

    2. The event-driven (pooled) actors share a thread pool and when calling react() they release the thread back to the pool, so in essence these actors don’t block the thread when there’s no message available. The thread can simply do something else.

    The send() methods in both types of actors don’t block since an instance of unbounded LinkedBlockingQueue class is used to hold messages by default and the messages are added using its put() method. Only SynchronousActor and BoundedActor, which are types of thread-bound actors, may block since they use SynchronousQueue or bounded ArrayBlockingQueue respectively.

    Let me know if there’s more you need to know.

    Best regards,

    Vaclav

Deixa un comentari

Fill in your details below or click an icon to log in:

WordPress.com Logo

Esteu comentant fent servir el compte WordPress.com. Log Out / Canvia )

Twitter picture

Esteu comentant fent servir el compte Twitter. Log Out / Canvia )

Facebook photo

Esteu comentant fent servir el compte Facebook. Log Out / Canvia )

Google+ photo

Esteu comentant fent servir el compte Google+. Log Out / Canvia )

S'està connectant a %s