- About Scala
- In the Enterprise
- Scala Community
- Language Research
- In the Press
- The Scala Team
- Scala's Prehistory
- Contact Us
- Learning Scala
- Tour of Scala
- Scala API
- Setup & Getting Started
- Programming Guides
- Other Guides
- Code Examples
- Scala Developers
Determining if actors really multi-thread
Tue, 2008-12-16, 16:06
OK, so I think I have a better understanding of how Actors work, but I'm
still not sure if Actors are appropriate for what I'm doing. Essentially
I have 3000 tasks that run once (no event loop) that use blocking I/O
over the network, and so have quite a bit of variation in their latency.
Right now, I can use the ExecutorService in java.util.concurrent
essentially as a task queue to set up the 3000 tasks, let them run and
then call shutdown on the ExecutorService at the end to wait for all of
the tasks to complete. As each task completes, it adds a message object
to a blocking queue, which a single thread pulls from to update a
database. I can easily see how Actors work in the latter half of this,
but I'm still not sure what the most appropriate method would be for the
first half. Here are the options as I see them:
1. Create one Actor for the tasks and submit 3000 messages. This has a
big drawback that the Actor only runs on one thread at a time, so with
the blocking I/O it could take a very long time to complete.
2. Create 3000 Actors, one for each task. Simple, but how much overhead
is there for an Actor instance? How far does this scale?
3. Create N Actors and divvy up 3000/N tasks to each one. Not exactly a
fan of this one since it requires manual partitioning of the tasks.
4. Just leave my code the way it is. It works fine now, so I don't
necessarily need to change it.
I really appreciate everyone's feedback on this so far. I definitely
understand Actors better now.