Comments on Programming Scala

Comment on 'Actors in Scala'

2009-07-13T11:56:07-07:00

Actors in Scala

After “opening the shop”, we generate a number of Customer objects, assigning a numeric ID to each and storing the lot in an ArrayBuffer. Next, we “trickle” the customers in by sending them as messages to the shop and sleeping for a semi-random amount of time between loops. At the end of our simulated day, we tally up the number of customers who got haircuts by filtering out the customers whose internal shorn boolean was set to true and asking for the size of the resulting sequence.

One other non-obvious issue: your Barbershop simulator and Barber could very well be using the exact same stream of random numbers if they both call Random() within 1ms of each other. It probably shouldn't give you adverse behavior in this example, but imagine you added "hair length" to your Customers which was determined by a random number generator at construction: all customers would have identical hair length. Even if you manually specified seeds (or there was more than 1ms delay), there could still be dependencies due to artifacts related to Java's weak random number generation (see my example at https://lampsvn.epfl.ch/trac/scala/ticket/2149). I'd like to see Scala references and docs make some warning about being careful with random number generation in concurrent programs.
— joebot (2009-07-13 11:56:07)

Comment on 'Actors in Scala'

2009-07-12T21:55:32-07:00

Actors in Scala

Lastly, know when Actors aren’t appropriate. Just because Actors are a great way to handle concurrency in Scala doesn’t mean they’re the only way, as we’ll see below. Traditional threading and locking may better suit write-heavy critical paths for which a messaging approach would incur too much overhead. In our experience, you can use a purely Actor-based design to prototype a concurrent solution, then use profiling tools to suss out parts of your application that might benefit from a different approach.

Will consider adding.
— deanwampler (2009-07-12 21:55:32)

Comment on 'Actors in Scala'

2009-07-12T21:55:02-07:00

Actors in Scala

Thanks for the feedback. Obviously, we're trying to strike a balance between keeping it simple for clarity, yet realistic enough to be applicable to nontrivial problems. Will consider what we can do here.
— deanwampler (2009-07-12 21:55:02)

Comment on 'Actors in Scala'

2009-07-12T21:53:51-07:00

Actors in Scala

The sleeping barber problem is usually solved with semaphores and mutexes, but we’ve got better tools at our disposal. Straightaway, we see several things to model as Actors: the barber is clearly one, as are the customers. The barbershop itself could be modeled as an Actor, too; there need not be a real-world parallel to verbal communication in an Actor system, even though we’re sending messages.

Thanks. will fix
— deanwampler (2009-07-12 21:53:51)

Comment on 'Actors in Scala'

2009-07-02T15:03:07-07:00

Actors in Scala

Some info on using Actors and futures (i.e. "!!") would be helpful
— joebot (2009-07-02 15:03:07)

Comment on 'Actors in Scala'

2009-07-02T14:57:11-07:00

Actors in Scala

I think this is a great example and a great toy problem! However, I find Thread.sleep(2000) to be a slightly unsatisfying way to wait for concurrent actions to complete. It's difficult to guarantee that all computation finishes by a certain time, especially if you were to use RemoteActors. This also skews any benchmarking you might want to do. Knowing how to end a concurrent problem gracefully is essential to many applications, although it's probably overkill for this example.

I like to have a definitive signal or message that computation has finished. I have gone about this by having the actors communicate with the coordinating class (which isn't explicitly an actor itself). I'm not sure if this is the best way to do things.
— joebot (2009-07-02 14:57:11)

Comment on 'Actors in Scala'

2009-07-02T13:42:27-07:00

Actors in Scala

Typo: "Actosr"
— joebot (2009-07-02 13:42:27)