This page is no longer maintained — Please continue to the home page at

Re: Re: Determining if actors really multi-thread

No replies
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
On Tue, Dec 16, 2008 at 10:05 AM, Derek Chen-Becker <derek [at] chen-becker [dot] org> wrote:
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.

My vote would be 4. It sounds like you could make this work with actors but that you wouldn't receive a massive benefit from doing so.

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