This page is no longer maintained — Please continue to the home page at www.scala-lang.org

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

8 replies
Vincent Marquez
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.


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

Vincent Marquez
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.
Questions about Actor pattern (wrapping public methods into acto
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
Derek Williams 3
Joined: 2011-08-12,
User offline. Last seen 42 years 45 weeks ago.
Re: Fwd: Questions about Actor pattern (wrapping public methods

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.

On Dec 27, 2011 4:20 PM, "Vincent Marquez" <vincent [dot] marquez [at] gmail [dot] com> 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.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

Ittay Dror 2
Joined: 2010-05-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Fwd: Questions about Actor pattern (wrapping public methods
body p { margin-bottom: 0cm; margin-top: 0pt; }

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:
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

Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: Questions about Actor pattern (wrapping public methods into

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
>

Vincent Marquez
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Questions about Actor pattern (wrapping public methods into
Thanks for the recommendation.  This is for a SIP server, and so I am shooting for good scalability, so I'll need to read up on the performance implications of the scala STM.  However, because there are multiple Actor implementations, I'm going to guess for the time being that the Actor approach would be a little more outwardly scalable than the STM one.
--Vincent

On Wed, Dec 28, 2011 at 12:05 AM, Sciss <contact [at] sciss [dot] de> wrote:
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
>


Vincent Marquez
Joined: 2010-07-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Fwd: Questions about Actor pattern (wrapping public methods
Thank you for the reply.  Oops, yes I need to 'wrap' my function in another one before sending the message.  Good catch.  It's also good to know I'm not completely off the wall in this approach and that others have utilized something similar.
--Vincent

On Tue, Dec 27, 2011 at 8:21 PM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:

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


roland.kuhn
Joined: 2011-02-21,
User offline. Last seen 35 weeks 3 days ago.
Re: Questions about Actor pattern (wrapping public methods into


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
roland.kuhn
Joined: 2011-02-21,
User offline. Last seen 35 weeks 3 days ago.
Re: Questions about Actor pattern (wrapping public methods into
forgot to say: in your example you really want to make _state @volatile. (not that I would recommend the approach, though)

Am Donnerstag, 29. Dezember 2011 19:15:31 UTC+1 schrieb rkuhn:


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

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland