Fwd: Questions about Actor pattern (wrapping public methods into actor messages for single threaded access)

Have you looked at Akka's typed actors? They should do what you want.

The way I do this kind of thing is put the state in the actor itself, and send messages that trigger actions on that state, or contain functions that modify the state.

I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!

---------------------------------------------------------------------------------------------
import scala.actors.Actorimport scala.actors.Actor._
class User {   private var _state = 0       def addState() = sendInternalMessage {    _state = _state + 1  } 
  def subtractState() = sendInternalMessage {     var tempState = _state    Thread.sleep(500) //still shouldn't be a race condition...    _state = tempState -1  }
  def state = _state
  private def sendInternalMessage(f: =>Unit) =    myActor ! f   private val myActor:Actor = actor {    loop {        react {          case f:( ()=>Unit )              => f        }    }  }}---------------------------------------------------------------------------------------------
--Vincent

This is how we worked in many cases (we even had an EvalActor class with 'eval' method). But note that you have a bug: '!' is strict so 'f' is evaluated before the message is sent.

i4LeSen9n1iCKhB5Ts5QQeb54CAyLkA [at] mail [dot] gmail [dot] com" type="cite">

I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!

---------------------------------------------------------------------------------------------
import scala.actors.Actor import scala.actors.Actor._
class User {    private var _state = 0         def addState() = sendInternalMessage {     _state = _state + 1   } 
  def subtractState() = sendInternalMessage {     var tempState = _state     Thread.sleep(500) //still shouldn't be a race condition...     _state = tempState -1   }
  def state = _state
  private def sendInternalMessage(f: =>Unit) =     myActor ! f     private val myActor:Actor = actor {     loop {         react {           case f:( ()=>Unit )              => f         }     }   } } ---------------------------------------------------------------------------------------------
--Vincent

unless you need massive parallel execution, i would think that using Scala-STM ( http://nbronson.github.com/scala-stm/ ) is much simpler for achieving thread-safety with your state

import concurrent.stm._

class User {
private val _state = Ref( 0 )

def addState()( implicit tx: InTxn ) { _state += 1 }
def subtractState()( implicit tx: InTxn ) { _state -= 1 }
def state( implicit tx: InTxn ) = _state()
}

best, -sciss-

On 28 Dec 2011, at 03:38, Vincent Marquez wrote:

> I'm pondering moving my lock based code in scala to an actor oriented approach. The goal would be to make sure anything modifying an object's internal state would be run single threaded. Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent. Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method? Thanks in advance!
>
>
> ---------------------------------------------------------------------------------------------
> import scala.actors.Actor
> import scala.actors.Actor._
>
> class User {
> private var _state = 0
>
> def addState() = sendInternalMessage {
> _state = _state + 1
> }
>
> def subtractState() = sendInternalMessage {
> var tempState = _state
> Thread.sleep(500) //still shouldn't be a race condition...
> _state = tempState -1
> }
>
> def state = _state
>
> private def sendInternalMessage(f: =>Unit) =
> myActor ! f
>
> private val myActor:Actor = actor {
> loop {
> react {
> case f:( ()=>Unit )
> => f
> }
> }
> }
> }
> ---------------------------------------------------------------------------------------------
>
> --Vincent
>

unless you need massive parallel execution, i would think that using Scala-STM ( http://nbronson.github.com/scala-stm/ ) is much simpler for achieving thread-safety with your state

import concurrent.stm._

class User {
  private val _state = Ref( 0 )

  def addState()( implicit tx: InTxn ) { _state += 1 }
  def subtractState()( implicit tx: InTxn ) { _state -= 1 }
  def state( implicit tx: InTxn ) = _state()
}

best, -sciss-


On 28 Dec 2011, at 03:38, Vincent Marquez wrote:

> I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!
>
>
> ---------------------------------------------------------------------------------------------
> import scala.actors.Actor
> import scala.actors.Actor._
>
> class User {
>   private var _state = 0
>
>   def addState() = sendInternalMessage {
>     _state = _state + 1
>   }
>
>   def subtractState() = sendInternalMessage {
>     var tempState = _state
>     Thread.sleep(500) //still shouldn't be a race condition...
>     _state = tempState -1
>   }
>
>   def state = _state
>
>   private def sendInternalMessage(f: =>Unit) =
>     myActor ! f
>
>  private val myActor:Actor = actor {
>     loop {
>         react {
>           case f:( ()=>Unit )
>             => f
>         }
>     }
>   }
> }
> ---------------------------------------------------------------------------------------------
>
> --Vincent
>

This is how we worked in many cases (we even had an EvalActor class with 'eval' method). But note that you have a bug: '!' is strict so 'f' is evaluated before the message is sent.

Vincent Marquez wrote:

I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!

---------------------------------------------------------------------------------------------
import scala.actors.Actor import scala.actors.Actor._
class User {    private var _state = 0         def addState() = sendInternalMessage {     _state = _state + 1   } 
  def subtractState() = sendInternalMessage {     var tempState = _state     Thread.sleep(500) //still shouldn't be a race condition...     _state = tempState -1   }
  def state = _state
  private def sendInternalMessage(f: =>Unit) =     myActor ! f     private val myActor:Actor = actor {     loop {         react {           case f:( ()=>Unit )              => f         }     }   } } ---------------------------------------------------------------------------------------------
--Vincent

I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!

---------------------------------------------------------------------------------------------
import scala.actors.Actorimport scala.actors.Actor._
class User {   private var _state = 0       def addState() = sendInternalMessage {    _state = _state + 1  } 
  def subtractState() = sendInternalMessage {     var tempState = _state    Thread.sleep(500) //still shouldn't be a race condition...    _state = tempState -1  }
  def state = _state
  private def sendInternalMessage(f: =>Unit) =    myActor ! f   private val myActor:Actor = actor {    loop {        react {          case f:( ()=>Unit )              => f        }    }  }}

Am Mittwoch, 28. Dezember 2011 03:38:24 UTC+1 schrieb Vincent Marquez:

I'm pondering moving my lock based code in scala to an actor oriented approach.   The goal would be to make sure anything modifying an object's internal state would be run single threaded.  Below is one way I could reduce locking while still having a public "API" opposed to simply allowing messages to be sent.   Does anyone have any ideas on other ways to accomplish this, and the pros and cons of using this method?  Thanks in advance!

---------------------------------------------------------------------------------------------
import scala.actors.Actorimport scala.actors.Actor._
class User {   private var _state = 0       def addState() = sendInternalMessage {    _state = _state + 1  } 
  def subtractState() = sendInternalMessage {     var tempState = _state    Thread.sleep(500) //still shouldn't be a race condition...    _state = tempState -1  }
  def state = _state
  private def sendInternalMessage(f: =>Unit) =    myActor ! f   private val myActor:Actor = actor {    loop {        react {          case f:( ()=>Unit )              => f        }    }  }}

sending code to the actor always feels a bit backwards to me: an actor is state+behavior, i.e. it contains the behavior. Countering with Akka syntax:

class User extends Actor {
  var state = 0
  def receive = {
    case Add(x) => state += x
    case Sub(x) => state -= x
    case Get => sender ! state
  }
}

Please note that Akka actors are encapsulated behind ActorRef (i.e. nobody can access the actual object and state does not need to be private). I left out the Thread.sleep() because it does not change anything (besides throughput). Of course this works best if you have more than only this part converted so that the whole processing can use message sends.

Regards,

Roland