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

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

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
>